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.
Related
Can MODX serve a single site instance to a subscriber-based audience, whereby common elements are served to all users, while each individual subscriber's content is stored uniquely and presented in the front end only to them?
To clarify this scenario, consider a website that provides financial budgeting tools. In this example, a single instance of the website and its components is served to all users, simplifying maintenance, progressive design enhancements, etc., while each user's data (i.e. their financial details) is accessible only to them via log-in credentials.
The default MODX setup does not to support this example. Static elements can be used, but this alone doesn't cover the above scenario. So my question is whether MODX can support the above scenario, and if so, how it can be accomplished? I'm not looking for specific details -- but broadly, what options exist? If there are options, is it even a good choice for this kind of scenario?
MODX does an excellent job with common pages, and the built-in ACL system will allow you to differentiate access for any number of closed participants groups.
As for the user's personal data, there are two possible ways: create some custom code or use an existing one. Each of these paths will almost certainly extend the current user model and use it for your needs.
Here are a couple of useful links regarding your question:
https://docs.modx.com/current/en/extending-modx/custom-users
https://docs.modx.com/3.x/en/extras/login/login.tutorials/using-custom-fields
https://modx.com/extras/package/classextender
I'm developing an application in ASP.NET MVC3 which uses CQRS pattern. The command side is made with Entity Framework, entities are mapped to tables in SQL Server. The query side is built on top of SQL views (also uses EF).
How should I manage the access to data? For example there is a Document. The Document could be protected with a password and accessible to any one who knows it or it could be accessible only for a given logged in users.
Where and how the logic of allowing/denying access should be implemented? What data should be included in the DocumentViewModel? Should it contain a password field to compare it with password provided by the user, so I could check access and get data for display in a single query? Or should it contain just fields that will be displayed in UI, thus a separate query (or stored procedure call?) will be responsible for checking access?
What if access rules are more sophisticated than just checking password - that might include all white lists, black lists, payments, transfer limits, account type, etc?
In general - things very far from
SELECT * FROM ReadModelTable WHERE id = #id
that is often showed in examples of 'good' read scenarios.
Episode 28 of Being the Worst (Podcast) has some interesting points on authorization and authentication for systems that use CQRS. I've often considered authentication after listening to others and coming up with theoretical system architectures as a concern normally outside of the core domain. Authorization on the other hand could have elements within the core domain but also seem to be somewhat cross cutting concerns in many systems.
In your example, if dealing with some type of document aggregate where each needs to have a separate user name and password then what your proposing would work but it doesn't sound like a typical implementation. The main failing point is that the credentials reside with the document and are presumably shared between users which is a security concern and makes revoking a single user's access rights in the future problematic. Think like a secrete club where each member needs to know the secrete password. If the password never changes then you have a problem when somebody gets kicked out of the club or accidentally shares the password with an unintended party.
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.
Question
Should autoincremented identity columns have a non-default seed/increment when used in a RESTful web application?
Background
I'm working on my first ASP.NET MVC application and trying to keep my urls RESTful. There is no separate administrative web site for the application. I use attributes to control who can access what parts of the site and what menu items are visible to the current user based on their roles in the system. I (mostly) follow the ActiveRecord DB pattern and use synthetic ids for my tables, including the user table, with the ids being autogenerated identity columns.
It occurred to me this morning that there is a subtle security risk to using default seeds for identity columns in a RESTful application. If you assume that administrative ids, particularly the most powerful ones, are typically created first in an application, then it follows that they will be the lowest numbered ids in the system. While not actually opening a hole in the application, using default values for the seed/increment could make it easier for a cracker to attack a high value target simply by targeting low numbered ids using RESTful actions (such as ChangePassword -- which is one of the out-of-the-box actions in the ASP.NET MVC site template).
Should I add setting a non-default seed to, at least, my users table to my arsenal of security best practices? Is the effect of doing this worth it? Or am I being too paranoid? As a related question, should I be changing the out-of-the-box template names for account-related actions.
My advice is to use GUIDs instead of autoincrementing IDs. That gets rid of the "guessing game" altogether.
I have been very skepticle of using Guid's; however, as Lucerno points out it does help minimize the guessing game depending on how the Guid is generated and used. Guids generated using sequential from SQL Server, would not prevent the guessing game for example.
Guids are also very handy if your have a domain model and your using an ORM like nHibernate or even rolling your own. As it simplifies greatly the complexity of inserting the backreferences since all objects can be given their id's early on.
With that said if your Id's are included in the URL they should be treated as very public data. Even over HTTPS a devious attack could get the whole URL. If your page requests any third party content such as Google analytics for example, the url query string and all, is sent to the third party as the referer for example.
Keep the logged in user on the session on the server side rather than passing it to the client - that way the client can never alter the user id in a malicious query.
I've decided, for now, that I'll address the risk by changing the default seed for autoincrement columns. This isn't hard and won't change the character of the application or the ActiveRecord pattern. Since these columns are also used for foreign key relationships I want to keep them integers to make the indexes more efficient.
I'm not planning on change the default actions unless a different verb makes more sense. Having the interface be intuitive is more important than hiding the action behind an obscure name.
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.