Is it practically possible for a malicious developer exploit your application by swapping a genuine .dll file for a modified one.
If so are there steps that can be taken to protect an app. Are there some types of functionality that should not be placed in .dlls for example?
As long a signature of the exports is known is very easy to replace a DLL.
It's also possible to reverse engineer the signature if it is not known.
To help prevent this problem you can use Code Signing, so you can verify the signature before using the DLL.
For .NET applications, you can sign the DLL. I'm not sure if something similar exists for non-.NET assemblies.
Anyone with write permissions to your application installation directory will also be able to modify your executable file, so trying to protect against DLL substitution is far from sufficient for many attack scenarios. Is there some particular scenario about which you are concerned?
You should also consider DLL injection, where by a malicious user can for example view passwords in your password fields.....
check out these links:
http://en.wikipedia.org/wiki/DLL_injection
http://www.codeproject.com/KB/DLL/DLL_Injection_tutorial.aspx
Related
I have been working with a Visual Studio project by myself for a while. and now we have a new coder with me. We are not sure yet how trustworty he is. so we need to block him to run or read the project source codes if he copied and take it to home or anywhere else except our environment with TFS. How could I do it, is it possible. Regards
EDIT: let me clear some points: I want a source code only available in office environment, in TFS, so developers can do anything with it but when they take it to the home, the solution wont run and display codes)
I am asking if this is possible. or is there any similar approach that I am unaware
There is no way to do this through TFS. You woul dneed to look at creating a secured desktop/remote session.
Even if you put him on a desktop that can't be taken home, you will have to disable USB ports etc. etc. so that he can't copy it over to his.her own device.
This isn't supported in TFS and I doubt it ever will. If you are worried about this then you need a tighter interview process. Have them sign non-disclosure agreements and such. Perhaps this is a case of paranoia, however there may be a slight alternative:
Get yourself a public/private key pair from a CA and sign your assemblies with the private key (which is known only to the 'trustworthy' developers or even just 1 of 2 senior members), have your builds compile using this private key (lock down your build server) and publish only these assemblies. Make your customers aware of this and give them your public key.
It will prevent people from stealing and publishing your source code under your name but it's a tremendous effort (and it won't stop them from outright theft and publishing as a competitor). If you are interested start looking up asymmetric encryption with assembly signing.
My classic asp application would run on local system of users via internet browser. The code file resides in the root folder of the C: drive. But I want that the code cannot be seen by the users, and even if the file is opened then the code is not readable easily, like encrypted or encoded. I want to protect the code from being copied. Is it possible? If so, then how?
Other way is to Host application on one System and if other system is in connected in LAN they can use same site via hosted URL.
To deploy code in each system is not a good practice to secure.
I will agree with everybody else, suggesting a different design, but I will give you an answer that I think is applicable if you're dead set on what you're doing:
Write your server-side logic in Visual Basic 6 or .NET and expose as COM objects.
(A wilder idea would be to implement your own ISAPI filter, but I am not positive if the APIs allow you to intercept the loading of the source... thinking and googling around make me think that that's not possible, but not 100% sure)
I have done this with COM objects.
I'm writing some ASP code to service requests from a simple HTML form on my company's intranet. The code needs to call methods from a (COM) dll. I'm using the code:
myObject = Server.CreateObject("myDLL.myClass")
but it's giving an error at this line. I'm not sure if the dll is registered on the server, but I suspect it may not be. I'm not sure how to find this out.
If it's not registered, is it possible/best practice to:
Use the dll without registering it on the server (I have the .dll file);
Remotely register the dll safely using ASP code; or
Do I need to contact the IT dept to get it registered?
I'm worried that option 2 might freak the IT department out and also possibly break something - but I have a deadline and it's unlikely that they will get around to registering anything before then.
Is there any way I can use the dll without involving them, purely with ASP?
I've also got this question open regarding running the dll on the client's computers by embedding in the intranet form, which is my preferred method if it's possible. It's the same dll, and it's already registered on all clients' machines but so far I've been unable to get it passed the IE intranet security settings.
ANY help/comments/suggestions on this or my other thread would be greatly appreciated.
Thanks for reading.
you need to register the DLL AFAIK, either with a setup program that does it, or manually with regsvr32 (or similar)
We have an idea of creating a page which would display information about all currently loaded DLLs (name and version). Is there any risk in terms of security, i.e. can a malicious user compromise the site security knowning the dll name and version number?
Knowing .dll version numbers is not inherently a direct risk, though it is good practice to give attackers as little information about your environment as possible. Consider at least protecting your page by requiring authentication and authorization to view it.
When I create an Azure ASP.NET application, by default .NET trust level is Full trust. I always change it to Windows Azure partial trust which is similar to ASP.NET's medium trust level.
You can do it either by using GUI when you select Properties on the Role or by setting enableNativeCodeExecution to false in the definition file (.csdef) just like below:
<WebRole name="ServiceRuntimeWebsite" enableNativeCodeExecution="false">
As a security conscious developer I want by default to run my application in partial trust mode that provides a higher level of security. If I need to use something like Reflection or P/Invoke, as a developer I want to make the decision to lower that trust level by myself.
I'm sure there's a reason why Microsoft decided to use Full trust as a default .NET trust level, I just fail to see it. If you know the reason, or you think you know it, please let me know.
Full trust is not only required for P/Invoke for .NET reflection as well. As a bottom line result, nearly all moderately sized apps need full trust because nearly all widespread libraries need it too (NHibernate for example). Actually, I have been asking from the exact opposite question on the Azure forums too.
The issue of full or partial trust pertains to the environment in which your application runs. The more control and/or "ownership" of the environment and assemblies you have, the more acceptable it is to have full-trust settings.
For example, if you create an Azure web site (July 2012 capability) and, mimicking wordpress or Umbraco, your web site allows arbitrary assembly plugins to be downloaded and installed, then it is important to have a partially-trusted environment. It is possible that one of the plugins downloaded and executed, which you don't control or own, contains malware. Not only does this impact the security and stability of your web site, but some may argue it impacts other (multi-tenant) hosted web-sites which have no relation to yours.
Certainly your web site will rely on 3rd party libraries, such as Log4Net or StructureMap, but those are extremely well-known and vetted libraries that are not in question regarding their security impact. Ergo, if you are running an Azure web-role (a much less "multi-tenant" type affair) and you are merely running such "trusted" 3rd party apps, then there really is not an issue with running as full-trust.
Yes, unfortunately it is still very hard (if not impossible) to write large .NET apps that run in partial trust.
We need much better technology and tools (like CAS.NET)
Because Medium Trust is now officially obsolete. If you start a new web project in Visual Studio, it already requires Full Trust (and doesn't work partial trust). Microsoft says: Do not depend on Medium Trust, instead, use Full Trust, and isolate untrusted applications in separate application pools.
Sources:
Stackoverflow answer: Quoted response ASP.NET team
Microsoft: ASP.NET Partial Trust does not guarantee application isolation
Microsoft: ASP.NET web development best practices