I have a ASP .NET application that we give to our clients for them to deploy it in their web server and use it. My concern is that all of my ASPX pages source code is open
and our clients can open the ASPX/CS file and see the code in it.
I want to protect my code something like a Windows application by implementing some 15-20 days trial limitations. Also on the other hand the source code must have some third party dll so that whenever they try to deploy the fresh build, it will be available for limited period only.
The payment terms with our client is, First Source Code and then Payment. So I am thinking some in between way that the faith at both side remain as it is. How can I do this?
Publish your web application so that all the code behind files are compiled into a dll. This way they cannot easy see your code. They will however be able to use reflection to see the code using tools such as jetBrains dotPeeek.
Best Option
Host the site yourself but as this doesnt answer your question here are some other options
1st Option
If the client insists on hosting the site as they are concerted about owning the data then allow them to host the site and database but pull in the functionality from a centrally hosted site that you are in control of. You can even provide an api.
You provide the client with a hash code in the web.config and this gets validated against your site.
The hash gets made up from:
presalt
the web service address
the expiry date
client uniqueidentifier
any other info you want
postsalt
Encrypt the request and response of the web service and send via ssl.
The client hash will be sent in the request. Build a new hash with the same fields and validate this against the hash you received from the client. if it is not valid you don't provide the functionality.
Google maps requires that you register and get a hash code as they can then terminate your usage of the google maps api if you misuse it.
2nd Option
Another option would be to setup a web service call to a site that you host.
The deployed compiled web application would then build a hash using the response from your web service and match the generated hash with the hash you sent over in the response.
This means that if the client block traffic to your web service or tried to fake the response then the application will stop working.
Also add some logic to alert you if they have tried to fake the response. This obviously wont work if they block the call to your web service.
You wouldn't include the salts here as the client could read them if they decompiled your code.
3rd Option
Add two fields to your web.config:
the hash code which you have generated for the client
an expiry date.
If the client changes the expiry date to allow them more time then it will not validate and they will be locked out.
Opion 2 and 3 would allow the client to reverse engineer the hashcode if they really wanted to.
=====================================
I don't really see the need for it but if you want you can use some obsfucation tools like mentioned in the other post to make it harder for the client to read your code. But even if they can read your code they should not be able to create a valid hash code on their own.
I suggest you check out .NET Reactor and Intellilock. .NET Reactor will prevent decompilation of compiled code, however with aspx I'm not sure how this will work since it would need to be pre-compiled. Intellilock will provide the ability to set an expiration time. I've used both with standard executables but never ASPX so I'm not sure if they'll help.
Link: http://www.eziriz.com/
DotFuscator Community Edition is a possibility, but it's probably too basic for your needs.
I suggest you look at the commercial obfuscators on the market. Here's a list of some I found with a simple Google search. (This is not a recommendation of any of these tools.)
.NET Obfuscator from Red Gate Software (I've used their Reflector tool in the past and it was good.)
You could make your own. See this StackOverflow thread.
Here's a thread on MSDN
Related
I have scoured the web looking for bits and pieces of a more comprehensive solution. I have been unsuccessful in my efforts, so I send up a call for help.
The problem:
I have a .Net/C# WebApp that uses windows integrated authentication. The application is a custom form application that allows users to submit requests. These requests are then routed to supervisors and other parties that will review and approve the requests.
For audit purposes, I must have each supervisor "Sign" the form. The easy solution - use the active browser session information. A user clicks the "approve" button and that information is logged into the database (ID and date/time). But the auditors don't like this solution. They view it as insecure. They want a separate challenge for credentials where users are forced to enter an ID and password (and very soon present a token/PIN combo in lieu of ID/password).
To satisfy this in an infopath version of this form, I used CredUIPromptForCredentials. That code (although written in C#) does not directly port to the new custom WebApplication. I did some digging and uncovered a number of resources on the newer CredUIPromptForWindowsCredentials:
How to show Windows Login Dialog?
Show Authentication dialog in C# for windows Vista/7
How to show authentication dialog in C# .Net 3.5 SP1
Windows Security Custom login validation
This is really in the spirit of what I'm trying to accomplish. With very few modifications to the code in the articles above (and borrowing from some code in my old InfoPath form), I was able to get a working system of prompting and testing.
I would be happy to share the existing code if anyone is interested, but it is VERY similar (nearly verbatim) to the existing code referenced above. The only difference is a separate isAuthenticated method that actually tests the credentials by instantiating a DirectoryEntry object and passing that object to a DirectorySearcher object to test if the credentials worked.
But no so fast. This code, as I said, works, but ONLY when I run in debug mode in Visual Studios 2012. If I visit the site by entering the address and click the button to "sign" the form, the site spins and never shows the security dialog. It's almost as if (and this is just my guess) the IIS settings that allow windows authentication are preventing the applications request to prompt for credentials. This is not the case when I run the site through the debugger.
Once I get past that barrier, I have to actually do some further testing to see if this code will support authentication with a PKI card. I am guessing it will since CredUI passes the prompting to windows to handle.
So here are the questions:
1) What could possibly be preventing the windows security window from popping up when the method is called through the IIS server VS running in Debug (localhost)?
2) Does anyone have any experience with implementing CredUIPromptForWindowsCredentials to work with PKI?
2a) If so, does CredUIPromptForWindowsCredentials actually support PKI without any additional code (assuming that the windows workstations are configured with all of the hardware, drivers, and middleware)?
Thanks in advance for any insight you can lend.
Phil S.
Looking your problem and as an old Auditor, may I recommend an detour to satisfy your auditing team? PKI is not the most safe thing around...
1) Provide a normal LOGIN/PASSWORD form, without any special instruction or Credentials (that could be frauded or stolen "on the fly"). Preferable, utilize HTTPS in this page.
2) Once the guy inform the data, pass a 2-Factor Authentication using SMS (INstant Message). The cost is really irrelevant (see Twilio to get some idea). Obviously, each guy, beyond his login/password, must have his phone within database.
3) This way you can ensure that the Supervisor is really the guy who had approved/sign the page.
It´s the safer mode and, because of it, Facebook, Google Mail and others are utilizing this method.
Sorry, I know I not answered you as you need, but it´s safer than your proposal.
Good luck!
We have a developer debugging tool to help manipulate security section of a database that our product depends on. This tool's purpose is to inject state into database to reduce time to create test scenarios. The database is not typical database that one can manipulate using sql. Rather it is a binary file that only our tool can manipulate. This is a C# application.
If this tool goes outside our company (say someone emailed it to a customer who shared it somewhere public), that could open lot of security issues.
We like to build intelligence into this tool so that it is usable within company or at partners network with whom we shared the tool. We have no knowledge of partner's network.
I am wondering what the suggested ways of implementing it?
Like:
Ping company active directory server or exchange server. Allow the tool usage if you can reach one of these servers.
Package a certificate with the tool that expires a month from build date. Always check if the cert expired or not before allowing usage of the tool.
Modification of (2). Make every user to request a key to unlock the tool after specific date.
Before we go implement a solution, I am wondering if there is already a library that does this.
Thanks
Assuming you host "file" inside your organization and all parties just access it somehow. If you give both data and tools to modify it to external partners there is nothing really to stop them to modify data as they pleased (short of legal/administrative actions but that is outside of SO scope).
There is also really not much you can do to protect code running on user's machine irrespective if it is C# or native compiled code. .Net code is a bit easier to modify/bypass protections but if you concerned about securing access to a file you need to protect files/servers rather than worry about client side code.
Usual solution to such problem - authentication and authorization: only allow authenticated users to access the file and only accept changes from authorized users.
If you use file based storage than inside your organization regular Windows domain accounts would work for authentication and regular file system permissions would work for authorization.
For outside partners you probably would need server to perform modification of the file(s) and authentication/authorization possibly using ADFS or Oauth.
My organization has a Win32 application that is written in the "fat client" style. I am writing a C# Client / Server solution that will replace this Win32 application. I am using ASP.NET MVC for the server and the client is a WPF application. I did my own custom implementation of the OAuth 2 spec. I am planning on creating a Restful API, and I want for not only my client to use it, but also allow 3rd parties to use it as well.
Every app will have an api key issued to it including the official client, but the official client's api key should be allowed additional api scopes (permissions) that 3rd party users aren't allowed to use. It is pretty obvious how to solve this but if you consider not everyone plays nicely, you have to ask "What would stop someone from just pretending like they are the official client and using it's api key?" Communication will be encrypted, but the server is not in the cloud or anything like that where we could control it. Our customers install the servers on their own machines and they will more than likely have access to the server application's SSL cert. Once you have that you can easily write an app that would run on our customer's machine that could glean the API key and secret from the official client app and use that info to request tokens from the server as if you were the official client.
I am planning on self signing the default key that the server uses and I could try and hide it in the application, but that really is just obfuscation. Besides, I wanted to allow users to provide their own SSL certs so browser based 3rd party applications wouldn't have issues with the browsers complaining that they are trying to communicate with on a self-signed SSL channel.
Is there anything I can do? Here are my choices as I see it:
1) I can set it up so that only SSL certs provided by us can be used and we hide them on disk encrypted using a secret that is obfuscated in the application code. We then just hope no one bothers to take the time to dig through our .net assemblies to find the secret used to encrypt/decrypt the certs on disk.
2) We allow them to provide certs so that we don't need to be involved with that process at all when they want to use a signed cert (we don't want to be in the cert business). Now we can't even hide behind obfuscation so if someone wants it, then the official client's API key and secret is easily obtainable.
Neither seems very desirable to me. Option 1 makes us have to request addition funds from them and manage SSL certs when self-signed doesn't work for them and in the end if someone really wants them they can still take the time to get them. Option 2 just makes it super easy to steal the official client's secret.
Reasons to want to limit unofficial Apps:
1. Discourage clones
A. Tell people not do it. Have a lawyer send cease and desist letters to authors of popular apps (and to anyone helping distribute them). Intermittently download them and alter the client/server code so that the popular apps will break. For added discouragement, temporarily ban any users who used the popular app. Authors will mostly give up on cloning your app; temporarily banning users will kill their install base. This is not great for your reputation.
2. Prevent unauthorized behavior.
A. Any behavior allowed by the official app should be allowed by the custom app. Whatever scenario you are worried about, block it server-side so that neither app can do it.
You can try to hide credentials (code obfuscation, hidden credentials, etc.), but this is only raises the cost/difficulty. This is often enough to discourage code theft (no need to make code theft impossible; it is sufficient to make it more difficult than copying it by hand). However, users who want to use your api in unsupported ways can work around this.
The answer is simple. each instance of you app should have its own unique key effectively a user sign up. You then ban users who infringe your rules. in this case signing in with a non authorised client. should be pretty easy to detect by pushing updates more frequently than it would be cost effective to reverse engineer them. Much like punk buster or other anti cheating tech
I have a program that opens a web browser control and just displays a web page from our server. They can't navigate around or anything.
The users are not allowed to know the credentials required to login, so after some googling on how to log into a server I found this:
http://user_name:password#URL
This is 'hard coded' into the web browsers code. -It works fine.
HOWEVER: Some smart ass managed to grab the credentials by using WireShark which tracks all the packets sent from your machine.
Is there a way I can encrypt this so the users cannot find out?
I've tried other things like using POST but with the way the page was setup, it was proving extremely difficult to get working. -(Its an SSRS Report Manager webpage)
I forgot to include a link to this question: How to encrypt/decrypt the url in C#
^I cannot use this answer as I myself am not allowed to change any of the server setup!
Sorry if this is an awful question, I've tried searching around for the past few days but can't find anything that works.
Perhaps you could work around your issue with a layer of indirection - for example, you could create a simple MVC website that doesn't require any authentication (or indeed, requires some authentication that you fully control) and it is this site that actually makes the request to the SSRS page.
That way you can have full control over how you send authentication, and you need never worry about someone ever getting access to the actual SSRS system. Now if your solution requires the webpage to be interactive then I'm not sure this will work for you, but if it's just a static report, it might be the way to go.
i.e. your flow from the app would be
User logs into your app (or use Windows credentials, etc)
User clicks to request the SSRS page
Your app makes an HTTP request to your MVC application
Your MVC application makes the "real" HTTP request to SSRS (eg via HttpClient, etc) and dumps the result back to the caller (for example,it could write the SSRS response via #HTML.Raw in an MVC View) The credentials for SSRS will therefore never be sent by your app, so you don't need to worry about that problem any more...
Just a thought.
Incidentally, you could take a look here for the various options that SSRS allows for authentication; you may find some method that suits (for e.g Custom authentication) - I know you mentioned you can't change anything on the server so I'm just including it for posterity.
I have a windows application developed in c#.Net which is used as a website blocker for a network.I have done this by modifying the hosts file.It works fine when urls are blocked like "www.yahoo.com".Now my requirement is I have to block the urls based on the keywords.i.e when the user just types "yahoo" in the browser,I should verify the keyword and block a corresponding website.Now how can I track the website typed by the user in the browser and block or allow the user to particular site based on the url.I should not allow the user to view the page if the keyword is present.How to do this?Can some one help me to do this?
There's plenty of code samples out there that will act as proxies (eg. http://code.cheesydesign.com/?p=393) however I would strongly suggest following the advice of the comments you've been given and go with an existing application.
Building a proxy that will not interfere with the complicated web apps of today is not trivial. You also need to be careful about blocking based on keywords - web apps I've worked on have failed in spectacular ways due to proxies doing this, and rejecting requests for important javascript files (often due to minification or compression) rendering our app useless.
Also consider that your proxy won't be able to check SSL traffic (which is increasing all the time) without serving up your own certs acting as a man-in-the-middle.