Develop Reference

How can I increase security on this project? [closed]

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 6 years ago.
Improve this question
Preface: I'm new to developing for secure commercial applications, and I understand that I may be too sensitive.
I'm working with a supervisor as a freelancer on a project that uses very truncated version of Forms Authentication and an SHA1 hash sans salt. The project uses no other security, and I've been explicitly ordered not to use any built in security that would ordinarily come with an MVC application, along with a few of the rendering/scripting libraries and the built in methods for role authentication or data annotation.
To the best of my knowledge, the application will not be interacting with legacy code, and the choice to use these methods does not lie in backwards compatibility with any already existing code bases.
The project uses a home brew method for encryption, roles, and security that uses a version of SHA1 and overrides or does not make use of many of the Forms Authentication methods.
Data stored by the application will include financial and personal records for a variety of entities and individuals ranging from small businesses to government entities.
I have mentioned several times that I am uncomfortable with the fact that the application does not use most MVC security tools, urged my boss to let me use more security, and have documented my issues with the project.
I have also spent hours reading on Asp.Net Identity and other tools in preparation for customizing them according to the project requirements while maintaining things I consider necessary, but was refused permission to do so.
Despite my worries, I want to finish the project if at all possible, preferably in a way that does not expose the users too badly or myself to legal ramifications for the kind of data that could be exposed here.
Given the following conditions, I would like to know if there are any specific ways to increase the security of this project:
Can't use OWIN/OAuth or Asp.Net Identity.
Initial authentication must be performed against the same table where sensitive user and financial information is stored in plain text. All subsequent authentication and roles management is performed against the home brew code, which stores session variables.
No salt may be used with passwords.
Password length is the only requirement for creating passwords, and the required length is very short.
Can't track or limit how many times a user can try to access or log into the system.
Can't use two-factor authentication.
Can't set the authentication ticket or security cookie to expire promptly.
Can't use data annotations for roles, authorization, and to some degree for validation on incoming data (some things have been nixed, others not).
Can't use anyone else's tools for security.
Can't create or limit roles using any of the built in classes/must use home brew method for limiting roles only.
Can't use the User.Identity object or methods.
In general, because of the nature of the data being stored, I am worried that the home brew security, coupled with the absence of current security tools, has created a situation in which it is extraordinarily difficult for sensitive information not to be exposed.
My communication with my supervisor is very poor. I'm hoping that any responses will give me more/better ways to communicate the vulnerabilities I'm seeing. No doubt I'm being annoying to my boss at this point, likely a contributing factor in our communication break down, but I'm very, very worried about all this.
And again, I am prepared to hear I'm being over-sensitive or that I am in the wrong. I am keenly aware that as a new developer, I have yet to develop a full understanding of the field. The vast majority of my experience has been academic, and I know that the classroom is not necessarily a good model for the actual practice of software development.
I'm also prepared to hear I should just finish the project and leave my boss alone.
But to the best of my knowledge, whatever that can be said to be, what I'm creating will be trivially easy to break, and I feel obliged to try and do something to make it a little harder for all the reasons above.

From what you've written here this sounds like the kind of project you would not want to be involved in. The constraints you listed sound like they are building a web app from the 90s. It sounds like they have covered all the bases as far as things you don't want to to if you plan to make you application secure go.
The only thing I can think of to say is that you should make sure they use https. Also, Captchas haven't been listed here explicitly, but they probably fall under 3rd party tools.
You should probably revise the homebrew codebase to see if you can strengthen it?
And you should probably have a long hard think about whether this job is worth the trouble or not...

Is it Possible to use Visual Studio/C# to develop for SharePoint 2007 without Deploying DLL to Hive

If a customer does not allow installation of a .dll into their SharePoint 2007 hive (or the GAC), is there any way to create webparts, etc. with Visual Studio that will not require deployment of the .dll(s) into the hive (or the GAC)? If not, is there another way to use Visual Studio and/or C# with the SharePoint namespace functionality in a similar fashion even if not quite in the standard way? This customer isn't going to allow us to install anything on the box beyond the pages and, if not into the GAC or hive, SharePoint-related .dlls developed by us.
Note: there are some specific project details at the end of the post.
Final Summary of Accepted Answer:
No answer was forthcoming with an alternative method of deploying custom SharePoint assemblies (e.g. not GAC and not hive).
It is possible, however, to use C# embedded in a page, and you may reference the SharePoint assembly and use it in the code. (see accepted answer for details)
Many of the things that I had expected would need custom code do not seem to, nor does it seem that in many cases it would even be possible/beneficial to do so.
I have a few basic ideas on how it might work ("magic happens"), but, being firmly in the "don't know what I don't know" quadrant right now, I don't know if it can be done, and I don't know whether any possible alternative route would even gain anything beyond just developing directly in SharePoint Designer sans C#/Visual Studio altogether.
ideas:
Develop with Visual Studio as normal, using WSPBuilder or a stock SharePoint project, but instead of normal deployment, installing the .dll(s) in a non-hive location on the machine, and then somehow including the items as an external resource.
Create a self-hosting web service that somehow can be called serve up components that can be incorporated into the SharePoint site.
Develop separate web pages/web controls in a non-SharePoint web project, then including them somehow into the SharePoint site; or, somehow creating a reference to them in the IIS directories
Develop seperate web pages/web controls in a WebApplication and using the Hostable WebCore to deliver what is needed, and, of course, somehow including the served up pages into SharePoint.
And, my final concern is that even should I figure out the details on the "magic happens" steps, I still would really not have gotten what I want, which is to be able to use the functionality of the SharePoint namespace in a useful way, e.g. connected to the site we are developing, and with sufficient access to do what we need without jumping through too many hoops, either from a developer perspective (e.g. code that's hard to use or maintain), or a bad user experience (e.g. user repeatedly getting login prompts).
(My apologies if the answer is obvious; I'm brand new to SharePoint development, and I'm only experienced with high-level Web development (e.g. fairly simple .ascx/.aspx, and mostly using the designer for pages), so I'm having to get my bearings quickly. When I search for help with the 'obvious' search terms, I get an overwhelming amount of information for normal scenarios, but have not found an answer for this.)
Upon request, here are the details that I can give about the particular project. I currently have information on only a piece of it, and it's a long-term project with a lot of pieces that will build on one another. So, unfortunately, if the solution isn't fairly generic, I will probably have to go the SharePoint Designer route to avoid the risk associated with relying on a method which may not be compatible with pieces that come down the road. Also, I apologize for how generic these are; I am trying to provide a list of capabilities needed as opposed to detailing the actual project.
ability to have individual user site home-pages that allow them to view various bits of information about projects they own and projects they are involved in
ability to have site templates that store wizard-type steps to be followed by users
ability to link the wizard templates to various documents and possibly other things associated with the various steps
ability to store various associated roles and attributes (such as how much time is allowed for a task to be completed) with the items in the templates
ability for a user to use the wizard to create instances of the site items and allow or enforce the assignment of other users based on the template attributes
ability for some roles associated with an item to edit the document and save it back, and to restrict others from editing them
ability for users other than the creator of the project (probably based on a project role assigned by the user) to view all info (timelines, etc.) and edit all documents in the project
ability for the associated users that have roles assigned to mark off when they are complete with their portion of the task
ability to calculate timelines based on info from the attributes for the different items in the project
ability to notify users (via email and site homepage notifications) in roles that have to take action or are marked as needing to received updates on one or more project items
ability to lock down project items from modification once a step has been completed; and possibly to unlock and/or retract steps
ability to automatically create reports and send them to appropriate locations (probably e-mail, but also possibly an administration page on the site, or to another site entirely.)
ability to mark completed projects and archive them in a separate section only viewable by certain windows groups or groups defined on-site
I also know that there is an intent to greatly increase the scope of this project once we complete the first part to the customer's customer's satisfaction. I am trying to find out more information and will post here if/when that is available.
I realize that some of what's there might really have nothing to do with SharePoint in particular, and some of it may not really give enough information to tell you which feature or other it will need. I am happy to clarify anything that doesn't make sense, but I wanted to try to give a little detail as someone else may have a lot better idea of what SharePoint pieces would be necessary or possible to use than I.

If you can at all wing it, you should see if it would be possible for an upgrade from sharepoint 2007 to 2010 to be made, because many of the problems you are describing are made a whole lot easier to solve in 2010.
Something that would really help me develop a more thorough answer is a very brief description of what functionality you are attempting to achieve.
OK, Thanks for the update.
I will try my best to address all the points of the project.
Your first point is easily available using something called a Mysite.
For all the points where you are discussing wizard templates that can store documents and associated data, you might want to look into Microsoft Infopath, no guarantee that it'll be a perfect match, but take a look and decide.
The great part about infopath is that when you combine it with Sharepoint Workflows, you can set rules for doing things, and different views, this will allow you to assign roles associated with editing privileges and such on documents.
Again, since infopath has the ability to easily submit to a sharepoint list or document library, any data based calculations are as easy as selecting which data you want, and what you want to do with it.
For the notifications, sharepoint workflows in microsoft sharepoint designer allow easy email creation.
As far as your last bullet point goes, this is another workflow, and the ability to make sites viewable to only certain groups is a basic functionality of sharepoint.
These are all available in SP 2007, but honestly, it would be financially more responsible as far as the difficulty and length of the project to use SP 2010. Also, the transition process is smooth and you don't really lose anything, just gain. From what you've said though, this might not be possible, which is a shame, but good luck either way!
This part should help you out with the C# pages, here is a basic hello world page.
<%# Page Language="C#" %>
<script runat="server">
public void Page_Load(object sender, EventArgs e){
Response.Write("<h1>Hello World!</h1>");
}
</script>
I normally code this in sharepoint designer. Also, say if you need to work with Microsoft.SharePoint.dll, provided on the server, you could add this line: <%# Import Namespace="Microsoft.Sharepoint" %>, since it is a page on the server, you don't need to specifically link it in any way, just that one little line after the page language declaration. Hope this clears everything up!

An option would be to deploy code to the BIN directory instead of the GAC.
The BIN directory runs with minimal trust. However, some things can't be deployed here (like event receivers).
See also, How to deploy a SharePoint web part to bin.

We have a solution which employs IronPython scripts. There's a IronPython web console, generic IronPython event receiver, page, workflow, timerjob, library of scripts which can also be edited through web interface, and a list with necessary configurations. I'm hoping to opensource the core of it at some point, but the full version can do a lot more.
The point is we don't need to do redeploys for every single little thing that needs to be added or changed for each particular customer. Particularly with workflows - we can do small changes without breaking everything that's currently running.

ASP.NET Completely modular design - how?

Technology: ASP.NET 4.0, C#, forms/mvc
I am a .NET web designer and I wish to create a modular based website for people, similar to what DNN does (but I want to create my own cut down version).
The idea is that I create a base website that can 'activate' features which the client needs (and has paid for). These features may be used by many clients which require frequent future updates for all clients (so I wish to keep upgrade time down to a minimum).
For example, I upload the base web application using web deploy and it sets up the core database tables/views/SPs in the process.
Then I login into the website as developer and activate the out of the box features that I wish to permit the user to take advantage of.
The only way I can think of currently is via user control, resources etc..
But I need a little of your experience and advice over what the possibilities / dangers are....
e.g. images for an application e.g. blog, that I have activated for a client - how do I reference those images
e.g. Can user controls be dynamically added to a web application (which is pre-compiled unlike a website - it must be a web application since I am using web deploy).
e.g. Modification of web.config to add additional routing (doesn't matter if app has to go down to do this).
The idea is that I can upgrade websites features en-mass, rather than manually enhancing each individual website which given a certain amount of clients would result in an awful amount of time lost.
I do not have access to sharepoint (nor do I intend to).
Any advice on how to automate modularity completely via a front end in asp.net would be superb!
My main problem is how to reference files and resources outside of the websites directory and without using virtual directories (ideally - but open to suggestions).
Thanks,
Dan.

I would suggest that your idea sounds like an ideal scenario for WebParts. There are lots of resources on how to go about building a WebPart management structure from scratch. Then, in terms of your 'bulk update' facility, it would simply be a case of tweaking database entries that are used to configure which web parts a user sees.
I'd be interested to know what you decide to do.
Best
Ian

Try a Multi-Tenancy Architecture as you can find some good info here :
http://codeofrob.com/category/10.aspx
http://weblogs.asp.net/zowens/search.aspx?q=Multi-tenant+ASP.NET+MVC+%E2%80%93&o=Relevance

Need help to Secure an ASP.NET Web Application

I'm working on a internal web application (only employees can log in) and need some help figuring out a good approach to handling an individual users permissions to the system.
The system itself is in C# / ASP.NET (4.0 / Webforms / Forms Authentication) / SQL Server 2008 and has several different areas which will have varying sets of permissions. You can think of it in a basic crud scenario (create, view, update, delete) though those would apply to different aspects of the system.
(I do want to mention this isn't a type of CMS system, so I can't pick an Open Source Project like DotNetNuke or anything. This is being developed from scratch. I can use open source libraries if they are available though.)
What would be a good approach to designing the User Permission system for a complex system with probably 5-6 different sections that have a good 10-15 different view/update/deletes contained in each section?
The goal here is to make it:
Understandable for Users (Admins) to use / set up.
Easy to Maintain Code Wise.
Easy to adapt as new permissions are needed (different types or in different spots).
There are two approaches that come to mind:
Approach 1:
Try to use the built in ASP.NET Roles system to define the different permissions and manage it from there. I could build custom pages to handle the different areas and assign permission sets to users. I believe that would also allow me to use the current session object by default to contain all of the permissions in the system for a user. (HttpContext.User.IsInRole() etc...).
Now, while I think that method would work, I'm not sure it's going to be easy to maintain or adapt to future needs. It seems like it'd be the quicker way to get it up off the ground and working but not the best long term.
Approach 2:
Roll my own. In this scenerio, I'd set up database tables to store true/false style permissions for each section of the application. Then I'd retrieve that information and place it in the session and basically access it anytime I need to check if someone has permissions to do something. I'd then build the custom pages to manage the lists, etc..
It seems this approach might be the more maintainable long term solution. It gives me more power in the set up and how it is handled. However, I'm basically still doing the work that the Roles system abstracts away for me in approach 1. I favor this over approach 1 still however.
In the end, I'm not sure if either approach is the best way to handle this. Can anyone help explain to me why either of the above would be good / bad? Or even to suggest a different alternative as to the "best" way to handle it in general would actually be. This is my first major undertaking in this area, so I don't have a great deal of experience in trying to "secure" an application like this by permissions. Any and all help is appreciated!

Use the built in approach, unless you've a specific architectural need not to. If you don't use the built in one, you can choose to roll your own provider implementations, but you should follow the same templates as the build in system, as it covers a lot of the security caveats that you should think about.
There's even the built in configuration page for quick and dirty user maintenance.

I would stick with the built in approach, you can always write a custom RoleProvider to match the roles and permission you need for your user base see (Implementing a RoleProvider)

Guidance for Migrating MS Access Apps to .Net Apps

I will soon begin the painful*(kidding)* process of migrating multiple, separate, Access Applications to "Real" applications*(notice the quotes, no flame wars please)*. Most likely this will be Web Apps as the usual reason is multiple users and deployability but I will take it case by case.
Some of these are traditional Access apps using Access as the back end and others are using SQL Server(a central one) as the back end.
What I am looking for is a combination of your experience doing this and what resources you used to help.
Websites, apps, standards, best practices, gotcha's, don't forget's, etcetera.
I am a 1 person C# shop with SQL Server back end so whether Web or not I will be looking that direction.
Also, is it overkill or unattainable to try and develop a Framework for this kind of thing? Would there just be TOO MANY variables to even try and walk this path? Anyone ever try this?
Some further info based on below questions. We currently have ~250 users and they are spread between 5 Locations.
What I meant by deployability is perhaps a little vague. I simply meant that we are a Non-Profit Organization and as such we do not have the best bandwidth available so deploying full apps, even through ClickOnce can be tricky when combinded with the highly fickle nature of my users*(I want that box purple, no green, no get rid of it altogether type stuff...)*.
My idea is to try and develop a "framework", of sorts, that will help to streamline the process of moving an Access App to a .Net App.
Now I fully understand that this "framework" may be nothing more than a set of steps and guidelines; like, Use ORM*(LINQ2SQL or SubSonic)*to generate DAL, Copy UI to corresponding UserControls, rewrite Business Logic.
I am just looking for your experience/expertise to help me streamline my streamlining process... ;)

Those apps which use an Access database to store tables and which need web access should first be upsized to SQL Server. There is a tool from the SQL Server group. SQL Server Migration Assistant for Access (SSMA Access)
Then consider moving to the web only that portion of the app that requires remote access. And leaving the rest of the app in Access. That could save a considerable amount of time.
Alternatively consider going to Terminal Server. That along with a VPN means just some software licensing costs and next to no work on your part.
That said what do you mean by "multiple users" and "deployability"? Possibly we can give you some suggestions there. Access is multi user out of the box. However if you have mission critical data or can't rekey the data in the event of a corruption or have more than 25-50 users on the LAN then you should be moving the data to SQL Server.
Now that it's public Access 2010 can deploy applications to the web. All kinds of very interesting stuff can be done. For more information check the Microsoft Access product group blog or my blog with the appropriate Access 2010 tags

Speaking from experience I think you would need to upgrade on a case by case basis. Upgrading is essentially a re-write from scratch and you should take the opportunity here to re-design as necessary. The type of application structure and code style used for Access (likely to be procedural I'm guessing) is very different to a well designed OO .Net app.
You will be able to re-use the SQL Server databases of course and, depending on the apps maybe even the Access ones. If you're feeling brave you could even try the upsizing wizard although I wouldn't recommend it as we found the results less than ideal.
I would also advise you take a look at some kind of ORM tool (we use Subsonic) as this can massively reduce the amount of boiler plate code you need to write. Some ORM tools will also generate DDL for your database too.
We follow these standards (good idea to pick a standard early on and stick to it we found) and also found this really useful to get up and running.
Hope this was some help.