I've a web application( ASP.NET WebForms). Now I need to give this application to my client for offline(Installed on Local Server and accessed via LAN) installation. I want to protect this application from being copied.
All I can think of now is:
I should maintain a online server and have a Activation Page which
runs when the Web App is run for the first time, It should connect to
the server and get a valid license against a Key(entered by me in
Web.Config during installation) and machine parameters.
Also, if I code it I need to take care of System Clock and other naive issues.
Now, I have two questions.
Are there any other options to safe guard a web app?
Does the solution I'm planning to code, already exists?
Thanks for reading and trying to help.
:)
No, no, no.. You can't tottaly protect your ASP.NET app like this..
Customer(if want to) can decompile your code and replace your activation methods, so application will allways think that it's "legally activated", or for example he can write fake activation server that will always activate your software... It's not so hard really, especially when your application is based on .NET.
This "protections" main purpose is only to make illegal copies creation little longer to do(for servial weeks or month-two..), so your selling departament can sell many-many copies to legal customers, and losses from illegall usage can be not so huge at project start time.. Or can be huge anyway even with usage of "super-super-super commercial protection product for you apps".. It's depends on luck and populariry of your app..
Only, and ONLY way protect your ASP.NET application with 100% guaranty from illegal copying is.. NOT TO give application to client for local install's at all. Use SSAS-model for selling your app. Or if it's not posible make this for some critical parts of your application.
Related
I am newbie to the web programming. I have been working as desktop application programmer for the last 8 years. Now one of my projects is to create a web application using HTML 5 and some java script that can be live on the cloud as well as downloadable as a desktop application to work offline. I don't need any database to store any data. I am thinking of writing a C# win form application with a web browser control to load the HTML pages and the .js files.
My questions are:
Is it possible to achieve? if so, is there any other way than what I mentioned above?
What about the security concerns such as accessing the files(the html files, java script files, etc)? Whether this can be called into my application from the local hard disk?
If I can run it as a desktop application, how to make sure that the source code is not accessed by anyone in the client machine?
It's achievable, but why you would want to wrap it in a C# web browser control doesn't really make sense to me. With HTML5 you can define cache manifest files to create offline apps that run in any browser that supports it, no need to wrap it with anything as long as the client has a capable browser. They don't even have to know it's an offline app!
Not quite sure what you mean here with regards to security concerns. That's a massive topic. Just use common sense and realize that anything you store on their computers will be accessible by them (e.g. do not give them your public/private key pair or store any passwords or anything you don't want them reading in the files you're sending to them) and use a secure connection to send sensitive data back and forth between the client and your server.
You really can't prevent anyone from accessing the source code if it's on their machine. The best you can do is obfuscate it to a reasonable degree before deployment to make it harder on the person trying to read it.
I have three applications running in three separate app pools. One of the applications is an administrative app that few people have privileged access to. One of the function the administrative app allows is creating downtime notices. So when a user goes into the administrative app and creates a downtime notice the other two apps are supposed to pick up on there being a new notice and display it on the login page.
The problem is that these notices are cached and being that each app is in a separate app pool the administrative app doesn't have any way to clear the downtime notices cache in the other two applications.
I'm trying to figure out a way around this. The only thing I can think of is to insert a record in the DB that denotes the cache needs to be cleared and the other two apps will check the DB when loading the login page. Does anyone have another approach that might work a little cleaner?
*Side note, this is more widespread than just the downtime notices, but I just used this as an example.
EDIT
Restarting the app pools is not feasible as it will most likely kill background threads.
If I understand correctly, you're basically trying to send a message from the administrative app to other apps. Maybe you should consider creating WCF service on these apps that could be called from the administrative application. That is a standard way to communicate between different apps if you don't want to use e.g. shared medium such a database and it doesn't force you to use polling model.
Another way to look at this is that this is basically an inter-application messaging problem, which has a number of libraries already out there that could help you solve it. RabbitMQ comes to mind for this. It has a C# client all ready to go. MSMQ is another potential technology, and one that already comes with Windows - you just need to install it.
If it's database information you're caching, you might try your luck at setting up and SqlCacheDependency.
Otherwise, I would recommend not using the ASP.NET cache, and either find a 3rd party solution that uses a distributed caching scheme, that way all applications are using one cache, instead of 3 separate ones.
I'm not saying this is the best answer or even the right answer, its just what I did.
I have a series of ecommerce websites on separate servers and data centers that rely on pulling catalog data from a central backoffice website location and then caches them locally. In my first iteration of this I simply used GET requests that the central location could ping the corresponding consuming website to initiate its own cache refresh routine. I used SSL on each of the eCommerce servers as I already had that setup and could then have the backoffice web app send credentials via SSL GET to initiate the refresh securely.
At a later stage, we found it more efficient to use sockets instead on the backoffice where each consuming website would be a client and listen for changes in the data. The backoffice website could then communicate to its corresponding website when a particular account change and then communicate this very specifically. This approach is much more granular and we could update in small bits as needed as opposed to a large chunked update but this was definitely more complicated than our first try.
I am thinking to use Silverlight instead of WPF as Client and WCF as server. Does it make sence?
I guess I will have these advantages:
1) More portable because it's Web.
2) I don't need to validate an user input in both client and server applications.
The third advantage is my main question: I guess the user cannot see my code, so my application would be safe against hackers. Is this correct? This means that if I store a database connection string in Silverlight, no clients will see it, right?
Thanks.
The .xap file in which your Silverlight Application is packaged is only an archive that contains the DLLs of your application (rename it to .zip and see for yourself) so your code can still be decompiled by anyone who downloads the .xap.
As for your 2nd point, you should validate on the server. I could, for example, sniff the traffic and see that your application calls a WCF web service. From there I could make my own requests to your service without using your application. If you don't validate server-side bad things will happen.
Also, the "portability" of Silverlight is arguable, but yes I guess it is more portable than a .exe.
1) More portable because it's Web.
Well you'd have to define what you meant by "web" here. It won't work (unless I've missed something) on iOS (using Safari), or Android devices, or probably some others. It's not "web" in the same way that, say, a pure HTML5 application is "web".
2) I don't need to validate an user input in both client and server applications.
That's only true if the server can "know" that the input really came from the client. If it's just a web request, it could be posted by anything. In my experience you should always validate on the server - client-side validation is there to make life easier for the user; server-side validation is to really enforce business rules.
The third advantage is my main question: I guess the user cannot see my code, so my application would be safe against hackers. Is this correct?
No. The code is running on the user's machine; it will have been downloaded, and can be decompiled like any other .NET assembly.
The assembly can easily be extracted and decompiled also you never can know that a request comes from your application if it runs on the client so do not even think about skipping server validation.
I have one application which is developed in ASP .NET MVC 3 which using a SQL server database.
Apart from this, I have one console application which calls an external web service and update the same database with the information and business rules. (Basically we iterate the records from Web service and process the business rule and update the same database), we have configured the console application with Windows scheduler to process it periodically.
The problem is, when my Console application runs periodically, it uses the 100% CPU usage (because we're getting more than 2000 records from web service), and because of that my current MVC application is gets haging OR sometime works very very slow because both application are configured on same windows server.
Could anybody please do let me know that How would I resolve this problem where I want both the things on same server because I have central database used by both application.
Thanks in advance.
You haven't given any detail that anyone can really provide resolution, so I'll simply suggest how I would approach it.
First, I would review the database schema with a DBA to make sure there aren't things like table locks (or if there are, come up with strategies to compensate for them). I would then use the SQL Server profiler to see where (or if) there are any bottle necks in SQL server while these things are running. I would then profile the console application to make sure it's not doing something it doesn't need to be doing. I might even consider profiling the web site to see if there's anything in there that might be contributing to slowness.
After that, I would figure out how to get rid of the Console application and work its functionality into the site. Spawning another application on a given web request is not scalable. More than a couple of those come in at once and you've got the potential to bog the server down very easily.
The basic question
How do I know that it is my publicly accessible (client) application that is sending my service messages? How do I know that it is just not some other application that is impersonating my application?
Some Background
Currently we log all errors that occur on our websites via log4net and WCF to a database. This works well because the web server (accessible from the web - Partly Trusted) reports there errors to the WCF service running on the application server (inaccessible from the web - Trusted) via a trusted relationship. We therefore know that all error logs are real and we need to investigate them.
With our new sites we plan to make use of SilverLight to liven things up a little. The problem we are faced with is how to report errors back from the SilverLight application running on the web consumer's PC (Untrusted) to our application server (inaccessible from the web - Trusted).
We can solve the inaccessibility problem of the application server by making the client communicate via a service facade on the web server, so that is no worry. The problem occurs when we need to be sure that the application sending the messages really is our application and not just an impersonator.
Some Thoughts
The code will be written in C# and be running in a SilverLight application that runs locally on the client PC, so we cannot be guaranteed that it will not be decompiled and used to send fake messages to our service.
The above means that we cannot make use of conventional symmetric encryption because we can't store our private key in the application (it can be decompiled). Similarly we can't use asymmetric encryption since it could just be impersonated (the attacker could just sign messages with the stored public key and send them - the messages would look real)
In the case of this application there is no user authentication, so we cannot use that to provide us with trust.
Yes, I know this is rather bizzare with the error logs being better protected than the data the application displays, but it is the case :)
Any thoughts or help would be greatly appreciated!
Impossible.
You can authenticate users, but not the application.
Let's say you decide to digitally sign the application. This signature is then read at runtime by your client application checking its own executable binaries against this signature. There is nothing that prevents the adversary from simply removing this check from your application.
Even if you make it close to impossible to reverse engineer your application, the adversary could always look at the communication channel and write an imposter that looks indistinguishable from your client to your server.
The only thing you can do is validate the actions on the server against a user identity.
Presumably, your server is creating the web page that the Silverlight application sits in. You could create a short-lived temporary "key" that only that web page contains. When the Silverlight app starts up, it reads this key and uses it. Because the server itself has a constantly changing, very short list of allowed keys, you can be more sure that only your app is accessing your services.
The best advice for you in this matter is to hire a security expert to help you. This is not a unique or unusual problem -- consider any game (like WoW for example) that is attempting to determine if it is speaking to a true client or a fraudulent client. Even with a massive amount of effort (look up Blizzard Warden, I'm not going to link it here), they still have issues. The problem boils down to exactly how much time and effort your attacker is going to invest in thwarting your attempts to make thing hard on him. Just be sure to validate everything on the server-side. :)