We have a grails-groovy(right now version 1.3.7) based application with Oracle 11g database.
We have to make it OWASP complaint so we are thinking of all possible security enhancements/plugins.
The main issue is here:
We have a create email template feature in our application where a user can create a new email template and save it. The Use has to write code manually in this template page to create the template. (The implementation is done we need to secure it!)
The code consists of
1) groovy code
2) grails tags
3) SQL select queries (we can restrict the user to readonly so that no Insert and Delete etc are available)
4) HTML tags
The template is used by the application where it compiles, executes and applies the template to emails before sending them out.
I know about markup-sanitizer plugin and the HDIV api and thinking about them, but how Can I secure this feature more?
I guess this is a feature where you have to trust your users. From my point of view, you can't sanitize this kind of markup - there are too many ways how to inject malicious code. (See book "Writing Secure Code")
When it comes to OWASP, you always have to analyze the threat: how likely is an attack and how much harm can be done. If only admins (which you trust) have access to this template engine, then I guess the risk is low.
Otherwise you have to create a template generator instead of a free-form templates. But even this sounds from your description to be a big effort since you would need an SQL query builder and some kind of template builder.
So I guess you should try to redefine the requirement in such a way that a secure implementation is possible.
Related
We use Orbeon with a custom REST interface with Apache CXF and we were wondering why does Orbeon Builder allow multiple sets of the same application/form?
Of course each set gets it's own documentId but on publish each form overwrites the other (given the same app/form)
So what was the idea behind that? It is manageable with a couple of forms but we are looking at 300+ forms with multiple users building forms with the builder.
Besides the possibility of user error when renaming a form and by accented overwriting another on publish it is quite a head ache from an administration point of view.
Speaking about the REST api:
We would like to return meaningful error messages from the persistence layer to the ui. Is that possible with the current builds of Orbeon and if so how? The 404/500 error message doesn't get displayed.
I hope Orbeon / another SO user could give us some insights about that.
It's mainly for historical reasons. We have an RFE to improve on this. Versioning, which is almost completely implemented now, will better allow handling multiple versions of a given form definition.
It's currently not possible to propagate error messages to the UI in the general case. It's possible upon Publish or when using the result-dialog when submitting, if the service returns an HTML response.
We've been having a debate at work recently about the merits of encoding output data from trusted sources such as an Active Directory. We have a web application that displays list of users that are queried from AD and allows them to be managed in various ways. The argument goes that if the data coming from the AD is not Html encoded, then it's possible to inject script and perform XSS style attacks against the site if you have access to the Domain Controller; for example by adding a script as the first name name of a AD user.
The two schools of thought (1 for not validating and 2 for validating) seem to be:
If you've got access to the DC, you can do a lot worse than inject code into a site which displays information you've already got access to. You could also just view the information directly. So why bother?
If you were a domain admin, you could craft this attack thus creating a backdoor which would enable you to get access to information even if you left the company.
I think the issue at hand is really a more generic one, do you need to guard against (and thus encode) output data from a trusted source, in addition to the common practice of guarding against malicious input.
It is good practice to always do output encoding. You've tagged the question with MVC, so I assume your web application is an MVC one. If you're using Razor views, output is automatically encoded. More details here.
I'm working with my team to create an enterprise level web application with Grails, but I don't see any "out of the box" solution to dealing with browser history when using grails with AJAX. Can someone point me to some documentation so that I can nail this?
Thanks a ton.
Grails is predominantly a server-side framework. All it provides in terms of client-side functionality are some tags to make it easy to call the server via AJAX. I'm not aware of any functionality in the core framework to support using the back/forward buttons when AJAX calls are made.
You might find something in a plugin, but I doubt it. Your best bet is to look for this functionality in whichever JS library you're using (YUI, JQuery, Dojo, etc.)
Typically this is done by changing the location.hash property on the page. This corresponds to a string you can add after the current url with a #. Adding or modifying this part of the URL will keep you on the same page, but add an additional history entry.
The jQuery BBQ plugin is a very useful framework to manage the hash. It contains a number of useful methods to manage the hash property as key/value pairs, the same way the regular URL query string works.
What's the best way to validate password and confirm password fields in a strongly-typed view?
Password Field Code:
<label for="BaseUser.PasswordHash">Password</label>
<%= Html.Password("BaseUser.PasswordHash", Model.BaseUser.PasswordHash)%>
<%= Html.ValidationMessage("BaseUser.PasswordHash", "*")%>
I don't know how to deal with confirm password field in mvc's way. Or just use javascript to validate?
This kind of UI validation rule might be done in the controller (contrary to my original answer). Download the Nerddinner.com source code, look at the AccountController.Register method where the ValidateRegistration method is called to see a specific example.
There's a complete walk through of the nerddinner.com site available as a FREE PDF download at http://tinyurl.com/aspnetmvc
but it doesn't go into the detail for your specific question in the walk through so just check out the source code as indicated above.
If you want to progressively enhance the user experience then you could layer the jquery validation plugin in the view to also validate client side.
Remember the danger with only performing the validation on the client via javascript is that all someone has to do is turn off javascript to avoid your business rules and bypass one layer of your "defense in depth" at stopping security attacks such XSS and Sql Injection.
I javascript is the way to go. If you want your validation routine on the server (what is it, anyways? standard mvc?) as well, then fine.
But why force a roundtrip for something as easy as "your passwords don't match". And if somebody wants to "hack" (e.g. turn off javascript) so that they can submit two passwords that don't match, then fine.
To do it on the server, you'd have two separate fields and if they don't match then you throw the error.
As a relative newcomer to both web and MVC, I am looking for a good summary of security best practices that I should implement.
The site will be public facing with "moderately sensitive data" (meaning we can't get sued, but probably wouldn't make many friends if the data got out!) and will have the following security steps taken:
a: Forms/membership authentication and authorization
b: Parameterized queries to prevent sql injection.
c: Automatic timeout with x min of inactivity
c: SSL for client to server encryption
What else do you recommend?
*Securing IIS and the network don't fall under my domain, so I'm more interested in the things I need to do to the software.
If you are using cookies to recognize users, be sure to use an arbitrary token (such as a GUID) to store on the client for identification. I've seen too many websites that store my email address or username in my cookie... just have to change it to another!
Write your software so that it can run under medium trust.
If you are new to web development you should be aware of cross site scripting (XSS). You can use Http.Encode helper method to protect against this in ASP.NET MVC.
Make sure you prevent out of order requests. Ensure client is authenticated before allowing to see sensitive data, or in some cases, make sure the client has come through the correct channel, before allowing a data manipulation. For example, only allow adding an item to your cart if the request came from the product details page. If you don't check, any one can mess around with the action. The URL would be like http://server/cart/add/XYZ123 and anyone could just tweak the 'id' parameter.
Here's another biggie to watch out for: CSRF
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Take a look at this post by Phil Haack- one of the MS dev’s involved in the development.
Additionally take a look at Microsoft Anti-Cross Site Scripting Library to filter out all incoming parameters
Maybe you should choose methods that can be invoke from outside or not. For example be careful make a method like delete any tables like http://yourhost.com/edit/deletealltable.
Make sure you design your class and methods well. And give attributes [NonAction] for preventing public method being invoke.
Make sure you display data (especially sensitive) as you need with minimum fancy design and use client script as long as needed.
Remove any unused trash files like unused files in your solution folder.
Check and double check and validate any input control like textbox. I just can give something in the textbox to hack your system.
If you use mix between MVC and regular ASP.NET, please remove any dependency between them.
Be sure you cover the basics thoroughly, independently of ASP.NET. Make sure your DBMS has a separate user with the minimal required privileges (e.g., CRUD and executing sprocs from specified databases) set up to access the database from the web application. Parameterizing queries is an excellent idea, but ALWAYS SCRUB YOUR INPUT ANYWAY: it is not a complete defense against sql injection.
Keep your design clean and easy to understand. Document whatever you do clearly, especially on the database side. It would be very bad if all your good work were destroyed by two programmers months or years later--one who didn't realize, say, that the database user for the web application (now accessing a database on a different server) shouldn't have root privileges, and another who added a control that didn't cleanse input properly. There's only so much that can be done about this sort of thing, but designing for the possibility that fools will be maintaining your code isn't so that coders will think you're sweet--it's so that fools won't put you out of business.