This project is read-only.

Dynamic compilation

Topics: Customizing Orchard, Installing Orchard
Oct 31, 2011 at 6:49 AM

Exactly how necessary is it to deploy the source for modules, etc? Having source on a production server is a pretty big security hole, and I don't require the ability to install modules, etc into the running site (ie, everything gets moved over from dev/staging together).

Oct 31, 2011 at 6:57 AM

No it's not a security hole, unless you expose an exploit for it. 100% of PHP applications are deployed in source code form. .aspx and .cshtml files are source code and can do whatever .cs files can. So no, that's not a security hole in itself.

You can deploy binary files, just by pre-compiling all modules and deploying their dll into bin, then removing all cs files, including the csproj. But what's the point?

Oct 31, 2011 at 7:24 AM

Thanks for the response.

All of our views, etc are deployed in an assembly - no source exists on the server. I'm aware that PHP, classic ASP, etc are deployed in source form, which is one of my chief complaints about them. In this case, regardless of my opinions on the matter, we can't put *anything* on the production system in source form due to some external business and regulatory constraints.

Oct 31, 2011 at 7:32 AM

Well, then maybe Orchard is not the right fit for you. I'm sorry that you are suffering from external constraints that are obviously unreasonable and not based on evidence.

Oct 31, 2011 at 4:38 PM

Yeah, it's sounding more and more like it's not a good match. Don't get me wrong - it's a very nice system and obviously a lot of thought and hard work has gone into its development.

The requirements have to do with the type of data we're handling (some assets with eight digit price tags) and some, shall we say, bad experiences in the past. For the benefit of any other readers, though, I think it's worth saying that I wouldn't hesitate to use Orchard for other sites.

Thanks again.

Nov 1, 2011 at 11:02 PM

@techvette: Thought for you: If you install a .NET assembly on a production server, you're installing something that can be pretty trivially decompiled to C#/VB source using free (e.g. Telerik's JustDecompile) or commercial tools (e.g. Redgate's Reflector).

And if you install precompiled native binaries on a server, you're also installing something that can be decompiled back into C/C++ code using free (e.g. Cristina Cifuentes' dcc) or commercial (Hex-Ray's IDA Pro) tools.

Security is NOT attained or assured by compiling code.

Nov 1, 2011 at 11:22 PM

Of course.

Ultimately an application, in any form, is just a list of instructions. Whether it's in raw machine code, IL or source, it's a task list which can be read by anyone with the required tools or knowledge. One of my first projects in college was writing a disassembler for the 68HC11 (which had been out of production for about a century even then). A good rule for coding is: if you don't understand it, you can't tell the computer how to do it. For reverse engineering, it's more like: if you don't understand what the processor's doing, you're screwed.

In this case, however, the goal isn't to defeat reverse engineering, or keeping anyone from getting access to the code (both of which fall under the heading of "security through obscurity"). The issue we're avoiding is having anyone randomly drop .cs/cshtml/etc files on the server and have them suddenly become executable. With .NET MVC, a custom view engine and a few other (surprisingly trivial) tweaks, we've managed to pull that off. Bi-monthly external security audits agree.

Perfect security is unachievable. You can put as many locks on a door as you want, but when the DEA shows up with a battering ram, on your knees, hands behind your head, and start chanting "Lawyer."


Nov 1, 2011 at 11:55 PM

Yeah, well, now people can't upload cs and have them run, but if they upload a dll, you're still screwed. But yeah, that's one more line of defense in a full arsenal, but probably a fairly trivial one, that I would not consider worth the price. Oh well.

Nov 2, 2011 at 12:04 AM

@techvete: All fair points, but if that's a concern you're worried about, why not ACL the files/folders so that only known parties with sufficient rights can modify the source files? You generally have to subvert the kernel to get past ACL's.

I agree with Bertrand: There has to come a point in any risk assessment where you say "yep, we have identified, understood and assessed the risks and that we're comfortable that our mitigations render the risks sufficiently impotent that we're comfortable".

Not sure you should chant "Lawyer" when the feds come a-knocking though - they may think you're claiming to be one - might not go the way you thought it might ;)