Fluid looks really nice if all collaborators are equal (allowed to change the same resources), but what I don't understand is how the server can prevent certain actions for certain users. As much of the logic as possible is on the client-side right? Maybe I haven't searched good enough, but I couldn't find a resource or readme that explained that part.
Example:
User A can edit the whole markdown document.
User B can edit the whole markdown document.
Both users can lock paragraphs they've created to be read-only, which only they can unlock again.
On the Fluid FAQ it states the following:
Turn-based games?
DDSes can be used to distribute state for games, including whose turn it is. It’s up to the client to enforce the rules of a game so there may be some interesting problems to solve around preventing cheating but the Fluid team has already prototyped several games.
If there is no solution for this problem, please let me know where I should start would I fix this myself. For a fun hobby project, I'm in the middle of deciding to build something new or to use fluid (which can save me a lot of work).
Right now, Fluid doesn't have the concept of Access Control, but we could include some related features as DDS features, we could implement some features as server-hosted Fluid Bot filters, and we could implement basic ACLs at the server layer as Storage ACLs.
As DDS Features
I wrote the "OwnedMap DDS" to show this concept, where users reject invalid changes from other users. This could be extended to include your "paragraph lock" concept, but I'm not sure it's rigorously secure.
I think it'd be interesting to build a library of "OwnedDDS" or DDS with filter methods on them to prevent invalid changes".
server-hosted Fluid Bot filters
Another option is to have a server side client, so a non-user client that joins the session that is not a malicious actor. This Bot could validate that changes are legitimate and then "consent" to the changes. This breaks some optimistic insert constraints, but would add more security and is more rigorously secure.
With this approach, you may still need to modify DDSs so that they're consensus based instead of optimistic, but the only consensus would be that the Bot agrees the change is valid.
Storage & Server level ACLs
You could imagine modifications to the routerlicious reference service where you need a user login to access specific containers. This is not as find grained as your request, but would clearly work!
Related
Can UUID on database level be used as a security measure instead of a true rights control?
Consider a web application where all servlets implements "normal" access control by having a session id connected to the user calling it (through the web client). All users are therefore authenticated.
The next level of security needed is if a authenticated user actually "owns" the data being changed. In a web application this could for example be editing some text in a form. The client makes sure a user, by accident, doesn’t do something wrong (JavaScript). The issue is of course is that any number of network tools could easily repeat the call made by the browser and, by only changing the ID, edit a different row in the database table behind the servlet that the user does not "own".
My question is if it would be sufficient to use UUID's as keys in the database table and thereby making it practically impossible to guess a valid ID (https://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates)? As far as I know similar approaches is used in Google Photos (http://www.theverge.com/2015/6/23/8830977/google-photos-security-public-url-privacy-protected) but I'm not sure it is 100% comparable.
Another option is off cause to have every servlet verify that the user is only performing an action on its own data, but in a big application with 200+ servlets and 50-100 tables this could be a very cumbersome task where mistakes could easily happen. In my mind this weakens the security far more, but I'm not sure if that is true.
I'm leaning towards the UUID solution, but I'm also curious if there are other obvious approaches to this problem that I ought to consider.
Update:
I should probably have clarified that my plan would be to use UUIDv4 which is supposed to be random. I know that entropy comes in to play here in regards to how random the UUID's actually are, but as far as I have read then Java (which is the selected platform/language) uses SecureRandom which is supposed to be "cryptographically strong" (link).
And in that case wiki states (link):
In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%.
Using UUIDs in this manner has two major issues:
If there are no additional authentication methods, any attacker could simply guess UUIDs until they find one belonging to someone else. Google Photos doesn't need to worry about this as much, because they only use UUIDs to obfuscate publicly-shared photo views; you still need to authenticate to modify the photos. This is especially dangerous because:
UUIDs are intended to be unique, not random. There are likely to be predictable patterns in your UUIDs that an attacker would be able to observe and take advantage of. In addition, even without a clear pattern, the number of UUIDs an attacker needs to test to find a valid one swiftly decreases as your userbase grows.
I will always recommend using secure, continuously-checked authentication. However, if you have a fairly small userbase, and you are only using this to obfuscate public data access, then using UUIDs in this manner might be alright. Even then, you should be using actual random strings, and not UUIDs.
Another option is off cause to have every servlet verify that the user
is only performing an action on its own data, but in a big application
with 200+ servlets and 50-100 tables this could be a very cumbersome
task where mistakes could easily happen. In my mind this weakens the
security far more, but I'm not sure if that is true.
With a large legacy application adding in security later is always a complex task. And you're right - the more complicated an application, the harder it is to verify security. Complexity is the main enemy of security.
However, this is the best way to go rather than by trying to obscure insecure direct object reference problems.
If you are using these UUIDs in the query string then this information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing direct object references into the URL increases the risk that they will be captured by an attacker. An existing user of the application that then has their access revoked to certain bits of data - they will still be able to access this data by using a previously bookmarked URL (or by using their browser history). Even where the ID is passed outside of the URL mechanism, a local attacker that knows (or has figured out) how your system works could have purposely saved IDs just for the occasion.
As said by other answers, GUIDs/UUIDs are not meant to be unguessable, they are just meant to be unique. Granted, the Java implementation does actually generate cryptographically secure random numbers. However, what if this implementation changes in future releases, or what if your system is ported elsewhere where this functionality is different? If you're going to do this, you might as well generate your own cryptographically secure random numbers using your own implementation to use as identifiers. If you have 128bits of entropy in your identifiers, it is completely infeasible for anyone ever to guess them (even if they had all of the world's computing power).
However, for the above reasons I recommend you implement access checks instead.
You are trying to bypass authorisation controls by hoping that the key is unguessable. This is a security no-no. Depending on whom you ask, they may refer to it as an insecure direct object reference or a violation of the complete mediation principle.
As noted by F. Stephen Q, your assumption that UUIDs are unique does not imply that they are not predictable. The threat here is that if a user knows a few UUIDs, say his own, does that allow him to predict other peoples' UUIDs? This is a very real threat, see: Cautionary note: UUIDs generally do not meet security requirements. Especially note what the UUID RFC says:
Do not assume that UUIDs are hard to guess; they should not be used as
security capabilities (identifiers whose mere possession grants
access), for example.
You can use UUIDs for keys, but you still need to do authorisation checks. When a user wants to access his data, the database should identify the owner of the data, and the server logic needs to enforce that the current user is the same as the database claims the owner is.
I'm trying to secure my play application but I have no idea where to start. In play tutorial I have not found any chapter about that topic. As far as I see security topic is changing between play versions. So what are You guys using to secure Yours applications.
I'm new in Play so please forgive me if I'm asking obvious questions.
Edit:
Ok, maby question was't clear enough(I'm really sorry about that). When talking about security I mean that I need something to deal with users credentials and tool which allows me to restrict access to some pages and eventually to some rest actions in my application.
Edit2:
I'll try deadbolt2 now and we'll see how does it works. But I still encurage You guys to share Your knowledge about Play security with others:)
The documentation seems to still be a bit lacklustre on this topic, but essentially, authentication/authorisation functionality is usually performed using Action composition, which is the basis of reusable controller code in Play. There an example here (also linked from the docs that should help give you the general idea.)
Action composition in Play 2.2.x is done using ActionBuilders. These take a block which accepts a request and returns a Future[SimpleResult]. This allows the action builder to either execute the given block, or return a different Future[SimpleResult] (say, an Unauthorized in the case that a user's credentials did not check out.)
In our app we use the Play2-auth module for handling authentication with session cookies. This has (just) been updated to work with Play 2.2.x but uses a slightly different mechanism for action composition (stackable controllers.) You might be best off working out how the precise functionality you need can be accomplished just using the native framework tools before adding a dependency to it.
I agree with the other answers but just add that I use securesocial to integrate with other auth providers (google, FB, etc...), so I don't have to do auth myself. It's quite easy to get up and running.
https://github.com/jaliss/securesocial
Access control, security, etc. is a very wide topic, because it means very different things depending on context. This may be one of the reasons why Play has little documentation for it, which puzzled me at the beginning as well.
Play2 has some security helpers, namely it's the Authenticated method, for some insights on how to use it, check the comments in the source code. Its a simple method that you could implement yourself, and most do. It, essentially, just proposes a structure for where to place your methods that would check if request is authenticated and what to do if it's not.
Play2 also has some cryptography logic, which is used for signing cookies.
That's about it, you don't have any more pre-built security structures, but that's a good thing, because you don't want the framework making decisions like that for you, if it doesn't know in what context it will be used.
What is essential is to go and research how attacks relevant to your application are carried out, best practices and so on. I recommend going to OWASP, particularly the OWASP Cheat Sheets. If the list of Cheat Sheets seems intimidating start with the OWASP Top Ten Cheat Sheet. Don't mind the large volume of information, it's very useful knowledge.
How can I communicate in a very simple and effective way the path the user takes through my application?
I'm currently working in a Ruby and Rails environment, so I tend to visualize my application in terms of RESTful URIs. So for example, if I want my users to sign up, I could match a new route called /users/new. The thing is, I would like to see beyond that specific action, and visualize how many pages or forms does it take to create an account and some business logic associated with the process in general. In other words, I'd like to see a mix of a workflow diagram and some implementation details (at an interface level).
I was thinking in showing mockup pictures wrapped in boxes, and relate them through arrows with their corresponding GET, POST, PUT, DELETE methods and URIs attached to them. I think it is a good idea, but I haven't seen examples yet that inspire me.
In your experience, what helps you see the big picture? Balsamiq mockups allow to define links and navigate through the app, but it doesn't help to conceptualize.
Have you thought of using a mind-map? You could try the free FreeMind
If you stick with UML, you could consider an Activity diagram.
I think you're on the right path. Showing different screens with possible combinations of users' transactions between them is a good technique. Basically you would be able to show user's flow through your application and stress out decisions a user will make on the way.
The good example for it was presented here http://vimeo.com/43869717
This technique called Storyboarding. You should be able to find some examples. But the one I mentioned above is one of the best Storyboarding techniques. I use it all the time to show the big picture and present application workflow from user perspective to my team.
From a usability perspective, is it better to integrate admin section on the main website or have a separate section to manage content?
Any thoughts are greatly appreciated.
EDIT: the application is a CMS for very non-techno friendly staff.
It depends on the project and part you want to administer, imho.
For example comments on newsposts should be administered in the website itself by showing a "delete" linkbutton for each comment. Otherwise the mods would have to look up the comment in the admin section => not very user friendly.
But in general I think a seperate admin section will usually be more clear to your client. You'd want them to see the site as a normal user would see it.
At the very least I would recommend moving all your administration files to a separate folder. That way if you're using a platform like .NET you can very easily control folder access though role and user-based web.config permissions.
Having your administration files all segregated allows you to do other things easily too, like delete them if you decide to move them to another server later. Also you can exclude them in your robots.txt file (although by putting it in the robots.txt file you will be telling other people this section exists, and robots don't have to mind this file).
Edit:
I feel like my answer missed the mark a little considering your question. Of course in-line editing is easier than going to a separate page from a usability perspective, but whenever I hear of mixing admin users with regular users giant alarm bells go off in my head.
I think that it depends on the function of the site and how intrusive it will be to your staff. Does it make sense for them to make changes while browsing the site and will they eventually become discouraged with your system because it forces them to inject unnecessary steps into their process? How long will the edits take? Does it make sense to show a completely different interface to administrators? I think an answer to this question requires a lot more understanding of what specific function you're trying to accomplish and will vary on a case by case basis.
I have never liked adding administration pages into the main site. It seems like it is too much of a risk from someone accidently getting access to the administration portion of the site. Even if you review the security over and over, there is always that possibility that something unexpected will happen, and it is a huge mess to clean up (what was modified, who accessed what etc. etc.). In my opinion keeping it as a seperate site is the easiest way to go.
While there is a level of convenience in being able to login to the main part of a site as a privileged user, and then clicking on parts of a page to edit/alter it, there is also a measure of security in having it in a separate area.
I have found that having a separate section of the website that is devoted specifically to administrative tasks makes the tasks easier to organize and use. Just look at Wordpress (especially the new 2.7 release), Drupal (a very popular cms), and Joomla (another very popular cms). If you would like to test these feature out to see why I think the separate section is better, you can go to www.opensourcecms.com and test out both Drupal and Joomla.
From a usability, the more integrated the better but it tends to add severely to the complexity. Its always best if you can perform the action within the context in which it occurs - lock out a bad user, trim a log thats too big etc. however since these tend to have significant side effects the security aspect trumps this a lot of the time out of fear.
I think you need to look at doing a risk assessment with regards to integrating the administration capabilities right into the application.
What would be the implication for the system if someone were able to escalate privelages and gain access to the admin functions. if every user was locked out maliciously - damage to the site, the reputation, SLA etc?
What destructive functions can an admin perform from this section ? delete lots of data? crash the app? alter costs that have material impact on users/customers?
Are the admin functions integrated in the app or isolated into specific admin functions?
Does the application have a public face or is it an intranet that is assumed secure?
I personally have never felt at ease integrating the admin section with the site out of fear that a security breach caused by my ineptness or something beyond my control like bad defaults, unpatched exploit. However, when the client is writing the cheque I tend to do what they feel is best.
I come from the school of Usability that says "minimise guess work". So, what kind of information did you get from your user group sessions?
Remember, you're not (and we're not) typical users of your system. Anything we say is going to be a guess. What's worse is that any opinion shown here is likely to be ill informed for your situation (but probably awesome at what they do). The only way you'll have an informed opinion on what to do is by going out and asking your users in intelligent ways.
Because this is a security issue some of your user mix should be people who specialise in security. Just because it's easier to use doesn't mean it's the most appropriate.
I'm building a website that will be an open-source, user-contributed content kind of thing, and I think if developers had access to nightly production SQL dumps, they'd be more likely to check out the code from github and play with it.
In line with that idea, I'm considering either:
Not collecting private user information at all, using open-id for accounts and making heavy use of memcache for things like session authentication.
Anonymizing sensitive data before publishing
Sometimes I get carried away with "wouldn't it be cool if...?" ideas, so I'm hoping for a sanity check here. Any obvious flaws in either approach? Is this a sane idea?
Speaking generally, I think you should do both. Any private data you collect is simply a liability for you, and not just because you intend to publish your databases. The less you can collect, the better.
By the same token, however, you probably realize that it is not just IDs and passwords which are sensitive. Remember the AOL search data leak? Or the Netflix database publication? Even without having IDs, people managed to figure out the real identities of some of the accounts, simply by piecing together trails of user behavior, and corresponding that with data from other places. Some people are embarrassed by their search histories and their movie rentals. Go figure.
Therefore, I think the general rule should be to collect as little as possible, and anonymize what is left. Even if you don't store the identity of the person corresponding to a certain account, you may want to scramble what the various logins did.
On the other hand, there some cases where you simply don't care about this kind of privacy. In Wikipedia, for example, pretty much everything you can do on the site is public anyway. At least, everything which gets recorded in the database. If the information is already available through the API, there is no point in hiding it in a database download.
In addition to collecting less data and anonymizing the data you do collect, you could add a bit/flag for the users to select whether their data is included or not. You could make it a CC license flag to give users the warm'n'fuzzies while filling your need.
Sounds like a pretty good idea. The one thing you have to be careful with though is security, since hackers will know the exact schema of your DB. Although this isn't impossible to deal with, just look at most open source projects. But you will need to put a little extra emphasis on security since say a potential SQL injection is now made much easier.
Another thing is to make sure doubly that the sensitive data is anonymized. Also, some people may (wrongly) try and claim their copyrights on user submitted content is being violated, so you may want to specify a CC license or something just to make everything extra clear and prevent future headaches (even if you're right anyway).