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.
Related
In your online documentation regarding domain services ("https://aspnetboilerplate.com/Pages/Documents/Domain-Services") you have section called "How do we force to use of the Domain Service?"
In there you imply that there is a lot of external documentation around the concept of injecting a kind of "policy" service into the entity as a way to do this, but the artice is kind of vague on the implementation of that class, along with where it should be injected and how it is used. I have been scouring the Internet for examples of this kind of design to force the use of domain services, but haven't been able to find anything.
Just browsing that documentation leaves too many questions..
Additionally, I was hoping I could find a simple implementation of an Abp that provided an example of this, but could not find anything.
I'm very curious about this because I have found it to be a big problem with large projects in the past: developers writing their own code in the application service layer, not knowing that the capabilities were already provided in some domain driven "Manager" service.
Can you provide a quick small sample of this concept fully implemented? Using Abp would be great, but a generic example would be fine as well.
take care,
jasen
A few thoughts:
The Policy pattern in that code plays no role in forcing use of the domain service. It is only making task assignment more modular and more SRP compliant.
There's only so much defensive programming can do for you. Sure, making AssignedPersonId protected so that it cannot be directly assigned is a good thing, but a programmer could just as well change it back to public. Don't rely too much on technical code to prevent bad developer behavior - shared practices and team culture are much more efficient.
Questioning application sample or template code (as you do) is sound. Don't take that code as gospel truth - it was never meant to be exemplary in the first place. Try your own stuff and learn from your mistakes. Experience is not something that can be transmitted through such a document.
Could somebody advice me the best solution about JavaFX (JDK8) and security concept? Under security I mean authorization and authentication. Thank you in advance.
I might be a bit late in answering this, but you are very right Maryan. JavaFx doesn't seem to have good interoperability with any standard security mechanisms.
The only option is to use a 3PP to solve this. Examples are: Spring security, Apache Shiro etc. In order to eliminate the dependencies with a particular 3PP, I encourage you to wrap the 3PP implementation.
Unfortunately, This is just the beginning of a long list of issues(that are yet to come up) for you, even after you implement the security measure, you will still have to come up with ways of storing and managing security tokens(similar to browser cookies) so that your JavaFx client doesn't need to authenticate with server for every call.
If this is only the beginning of your project, I suggest you really think about whether to use JavaFx or go with web based UI.
First, let's define "best" here. The "best" login design/flow/algorithm/technique for the purposes of this question should be:
Simple. I don't think I need to explain why a simple system is better than a complicated one. OAuth 2, for example, is a very complicated system in my view. It defines, if I recall correctly, no less than nine different flows for granting an application access to a person's data. I find this superfluous, but that's not up for debate here.
Language-agnostic. Please do not answer by giving an implementation. I don't want an implementation. I want a design (or several...). You can give examples, but the solution you propose should be easy to code in any (read: most) language without requiring significant workarounds for features that aren't there.
Secure. The design should cover most common security problems on the net. XSS, CSRF, etc etc etc. I think a good set would be obtainable by going to Coding Horror and searching for "security"...
Now for some smaller details:
JavaScript is allowed. If a design can fall back to noscript environments, cool. But it's not a requirement.
Flash, Java applets are not allowed. This goes against the language-agnostic clause above: if your design requires something that is only available through Flash or Java, it's a flaw.
Password storage. There's a whole class of problems related to password storage. I don't want to hear about it.
Password transmission. This is important. Transmitting a password in plain is just plain evil. Over SSL, it might be acceptable, but if you can have a system that is (relatively) secure without relying onto end-to-end encryption, it would be awesome.
Given all this, propose the "best" user/login/logout design/flow/algorithm/technique you think fits the conditions outlined above. Or tell me if you think it's a fool's errand! ;)
I think you have already given some thought to this question. Easiest way to look at the solution is to break it in to different layers.
1) Database
Protected against sql injection. Just use prepared statements. Best and most secure!
Always and I mean always, make sure the db user has only the access privileges it needs.
2) Application
Use HTTPS. Don't even try to use anything else
Don't store user-id in the cookie or anything. Use session's if you must
If you don't have a session, generate a random id use that to look up a user. It's important to not have the cookie id not predictable.
3) HTML/Javascript
Protect against CSRF by doing a token system. This is the only legit way
Escape all you user input and sanitize it before writing to stream. In JSP, for example <c:out/> should be used
Don't do anything secure in javascript. This is an obvious answer but sometimes it good to remind
4) Etc
Keep patches up to date
Don't recreate the wheel. In Rails, there are already some excellent authorization gems. Use them!
I think out all of these, using SSL is the most important. You can create the most complicated system to do a double submit with an awesome encyrption algorithm. But with all of that, at the end, you still won't have a system that is more secure and better tested than SSL.
Interesting question.
I would consider:
When required I think web content should be public. So, as a user, I think it's best to have login only when it is required
SSO We should have mechanism to cross connect web applications more easily. I know that applications do not implement permissions the same way and we can't go wild there. That's where OAuth is filling the gap.
Do not use CAPTCHA (it is considered inaccessible). Unless you use something similar, like these
csrf hidden field to make sure that the form that are submitting is a valid one and not a random post to an endpoint
Always use SSL the big guys is doing it and it's unsafe to let our users send their passwords in clear text. Some proved it.
Always plan for without javascript Just in case, anyway it's not because we can do it that it's good to do.
That's my timeout for tonight. :)
I am investigating SCORM compliance as an option for a software project I am involved in. If this is too esoteric for SO, I am sorry - not sure where else to turn.
I am a little confused as to how the SCO (Sharable Content Object) reports a quiz score, for example, to the LMS. From what I can gather from the official documentation, this is to be done using using LMSSetValue function in the RTE API object, which is just a bunch of Javascript.
This seems wildly insecure to me, as it takes nothing to rewrite the values passed to the LMS this way.
My question is therefore, am I missing something? Are SCOs meant simply to not report such values to the LMS? It is my impression it is the only permitted mode of communication between SCOs and the LMS.
The JavaScript API is the way data is passed from the SCO to the LMS. Are there more secure ways to pass data? Sure. But the implementation is not brand-spanking new, remember. In addition, because of portability constraints, many of the most highly secure ways of passing data are not available to SCORM developers. Portability was the main priority of the standard, not security. There is a community of experts talking about what should replace SCORM. It's called Project Tin Can. And different ways of exchanging data, including cross-domain and server-side, are being discussed there.
I will soon be developing an application to log and priorities worker shifts. It only needs to be small, and simple, but I am wondering what framework to use. All that needs to happen is boxes with names are in 3 lists, and the user can switch these around at will. It must log the times, which I will need access to in real time.
Im new to application development of this sort, and would like any suggestions. I have time to learn new technologies / languages.
Portability / device independence would also be useful. Should I consider a Web Application in Javascript? or something more like Python.
Thanks.
Even if your application is going to be simple that does not mean that whole system will be simple too. I can imagine that your app will serve only as a front end to something much bigger. If that is a case and you really have freedom to choose what language you will develop your app with consider choosing something that you will feel comfortable to work with. But before you will make your decision I would go to whoever gave you that task and try to get as much information about it as you can because expected features can help in choosing technology.
First of all, it seems that it is up to you to decide if it should be web or desktop app. In my opinion it is completely wrong situation. You should get clear requirements on what kind of application customer expects and in what environment it should work. And I would not move a finger towards a code before somebody gave me that information. You write that portability and device independence would be useful but is it actual requirement or you just think it would be nice feature to deliver?
EDITED (to answer a question in comment)
Probably there is as much possible solutions as people that would answer you so in the end you will have to make your own choices.
One way of doing it (considering that you want to learn something new and have a challenge :) would be implement WCF service that would act as a data provider from your database (so every GetUsers(), GetVacationDays() methods would be in it) and it would take care of some business logic (for example CalculateMaxValidWorkingTime() or whatever). That service would be a real power horse of your system. Since you don't have clear requirement whether it should be desktop or web app you could satisfy both possibilities by creating thin clients that would communicate with your service and they would be just a pretty front ends. And if you keep in mind that you can consume webservices practically with everything from C++ to .NET (C#/VB) to Javascript to Python to PHP after you done with service you would not be constrained with one particular technology/language.
Regarding databases I won't advice because personally I hate dealing with them and it always was somebody else's task to provide me with pretty API :)