I would like to turn one of my form applications into a web form using ASP.net (C# backside). It is my understanding that the App_Code directory will protect code behind if the classes are underneath the directory.
How safe are classes under this directory? Are they somewhat safe against people stealing the source?
I know with .net form applications you can run the reflector software on them to get the full source... unless you obfuscate the file (to make it more difficult).
Classes (or files) in the App_Code directory are compiled into an assembly with automatically generated name. Even if you deploy a non-precompiled Web Site, it will be automatically compiled during first run.
In addition, App_Code (as well as App_Data, etc.) is not available by a direct URL. E.g. it is impossible to get any file using the following URL:
http://mywebsite.com/App_Code/KnownFileName.cs
Moreover, IIS has many filters that prohibit requests to *.ascx, *.asax, *.cs, *.vb, *csproj, *vbproj, *.mdb and many other files. See Request Filtering feature in Web Site settings in IIS Manager for details.
So, your code is in safe unless you changed default ASP.NET or IIS settings.
Related
In order to use C# 6 features (like ?.) in a .cshtml file under MVC5, you need to include csc.exe and related files in your website's bin folder when you deploy it. Ok, I can understand the reasons for that.
However, this now means that there's a full C# compiler sitting on my webserver, with the same permissions as the website user. This makes me hesitate - in theory, an attacker could use it to run arbitrary code as if it were my website.
Is this actually a valid security concern?
I can see both sides: On the one hand, it's possible that you'd need the ability to execute arbitrary code already in order to be able to pass arbitrary code to the csc executable. On the other hand, I can see access to it being used to get access to internal website settings (like database connection strings) by running code that we'd never want to write.
Should I be concerned, or is this considered safe?
As I understand it, MVC Razor views are in effect arbitrary C# code, which is recompiled on demand after any change.
So any hacker with access to the website server can run arbitrary C# code, in any version of MVC.
I agree it feels like a risk, because it is, but on the other hand you get the advantage of being able to change Views without republishing the whole website.
I'm new to web programming and have a question about code behind in ASP.NET C#. How safe is it from someone seeing what's in it? The reason I ask is the program I'm linking this website to requires me to create an object that takes in my admin credentials (It does this in the background thousands of times or I would just prompt for creds). It uses the credentials to create things dynamically. I'm 99.99% sure this is highly unsafe to hard code my credentials into the page but I figured I would ask.
The code behind files and raw aspx files are protected from being retrieved by the web server, so as long as you control console and file share access to the server you are relatively safe.
Still, it is not considered really safe. You should set up the application pool of the site to run under a specific account and then give that account the necessary rights. Having services using ordinary user accounts is considered bad practice. Each service should have its own account, with least possible rights.
ASP.NET pages are compiled before sending the page over HTTP. This is secure. But if the user can access the file system, you have another problem on your hands.
You should put your credentials in your web.config (or you can move them into separate files like AppSettings.config or ConnectionStrings.config etc). The server will should never serve these.
This might be helpful:
http://msdn.microsoft.com/en-us/library/4c2kcht0(v=VS.100).aspx
This tells you how you can can go one step further and encrypt these so they do not store plain text password etc:
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
It is "safe". IIS (by default) does not serve up .cs files.
Another option is to precompile the site and then just drop the .aspx files on the web server.
Putting sensitive information into .cs files in ASP.NET is by default not a risky process as ASP.NET does not give access to .cs files from the client side (if you don't change it explictly), however, be sure that if there is a server error, custom errors reporting mode does not send the lines of the code to the client (which is extremely useful when debugging, and extremely risky when you release it to the public) or anyone may be able to read your sensitive information if an exception is thrown near those lines.
There are various levels of "safe" here.
Yes, IIS is configured to not serve up .cs files or .config files. That said, there are attack vectors which have proven successful in getting IIS to deliver those files into the evil doers hands.
First off, I wouldn't deploy .cs files to the server. If possible convert the web site to a web application and deploy it compiled. Of course, .net code can be decompiled (and here); so you should also look into obfuscation. However even obfuscated code can be decompiled but it's generally harder to read. ;)
Note that each level isn't really "secure". It just makes it more difficult.
The real answer is to not store the credentials on the server at all and require them to be provided by the client over an encrypted transport. Certainly you could cache them in memory, but even that has proven insecure to those with physical access.
At the end of the day, ask yourself how valuable the keys are and how much money/time you can invest in securing the system. There's usually a balance somewhere.
I have searched for two weeks, every night, exhaustively reading forum threads and trying all suggested solutions no matter how outlandish. Just as is the case with the many many forum threads about this same issue, the site works fine on my development machine. It deploys with no errors. It works from the production server and reads data from the database, but when it attempts to access a profile it crashes with this error.
A number of posts say to check or uncheck an option called "remove app_code.compiled file" but apparently this was a Visual Studio 2005 option. It is nowhere to be found in Visual Studio 2010. A number of posts say to make sure the App_Code.dll is present in my bin directory. It is present. I've deleted the app_code.compile file manually to see if that made any difference. I've changed the target framework from 4.0 to 2.0 and 3.5. I've completely deleted the site in IIS, created a different folder with a different name and redeployed the site with every combination of "allow this precompiled site to be updatable" and "Use fixed naming and single page assemblies". I've included references to System.Web.Profile and System.Web and System.Web.Profile.ProfileCommon. I've created a new, fresh website targeting .net framework v4.0 and copied that web.config file to my application and recreated my profile entries to ensure that I didn't jack anything up in the config file along the way. I've burnt candles and used voodoo charms. I've prayed. I have quite literally tried every conceivable suggestion on every forum thread pertaining to this error on the first five pages or so of returns on both google and bing. I have spent 14 days doing almost nothing but trying to get this website to come up without this error.
One post said to ensure there is a reference to the app_code.dll in the bin directory. I don't know how to do that, since it's created dynamically.
Does anyone have any fresh ideas on this?
Okay, I’ve been doing a lot of reading and experimenting on this topic, and I think I’ve gathered and compiled enough information to be helpful to those who might stumble across this thread by searching for this error. What I will do is simply offer a colloquial explanation followed by several links to very relevant information.
There are two distinct web design methodologies supported by Visual Studio; web applications and web sites. This is true of 2005, 2008, and 2010. This division of design principles stemmed, apparently, from the fact that Visual Studio 2003 only supported the web application model and this model was changed with the release of Visual Studio 2005, then in order to make design principles consistent with previous versions, the Web Application methodology was added to Visual Studio 2005 creating a very confusing fork in the road for developers of, apparently, even respectable skill levels.
I won’t go into great detail on the differences between the two models. There is plenty of detail in the links at the bottom of this post. But suffice to say that profiles are NOT supported out of the box using the web application functionality.
Furthermore, to make matters even more confusing, and this is what has been tripping me up, profiles will not work with the web site model either if the site is published via the Build -> Publish Web Site menu option unless (maybe) it is pre-compiled manually first then the pre-compiled dlls are copied over via “copy site” or FTP or whatever you use. Pre-compilation is, apparently accomplished via the command line. I have a link with instructions on how to do it below. But again, I haven’t tested this myself, so I don’t know if it even helps.
The reason it profiles don’t work with the Build -> Publish Web Site method of deployment is because the ProfileCommon class is built dynamically with the profile properties you define in the web config when IIS dynamically compiles your page the first time it is accessed. If you use the “build -> publish web site” option it compiles your DLLs just fine, but it does not create this class for you.
Honestly, I’m not sure why the Build -> Publish Web Site option is included in the website model in the first place. From everything I’ve read, the very point of the Web Site vs Web Application model is to make the ASP.net experience more like a traditional web development experience, where your files can be edited on your machine and FTPed to the server or can simply be edited on the server. Yes, they have to be compiled before they are accessed, but that compilation, by design, happens dynamically, and, apparently, if you compile the site first then upload it you compile it without dynamically creating the ProfileCommon class and therefore effectively take away one of the great features of the asp.net approach to website design.
There are a number of posts where people express concerns over the security of their code, because using the web site model and copying their files to the server for dynamic compilation means the files with the source code sit on the server in a precompiled state. However, I just don’t see a difference between this and any other more traditional web scripting language like Perl, or PHP, or even classic ASP. In those languages the code sits out there just as vulnerable. Any code is vulnerable on a misconfigured server. Furthermore, even if your code is compiled, a hacker with the skill to circumvent the security of a well configured IIS server and get at your source files could just as well get at your compiled files then just run them through ILDASM. So unless they are professionally obfuscated, what’s the difference?
So, from what I’ve discovered, if you want to use profiles on your asp.net website, create your site as a Web Site Project vs a Web Application Project and copy it over to your server instead of Publishing it via the build menu. You might be able to pre-compile it then publish it (not sure about that one) but I know that simply copying it and letting it dynamically compile works.
If I’m missing something and there is another way, I’d love to read about it. Meanwhile here are some incredibly helpful links. Much thanks to 5arx for setting me on this path:
http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
http://msdn.microsoft.com/en-us/library/dd547590.aspx
http://msdn.microsoft.com/en-us/library/ms227972.aspx
Are you saying you can't access the profile in code? If so could you post some code/pseudocode pls? I think this is an issue I encountered last week (and fixed) ... – 5arx 11 mins ago
Had a similar problem last week - converting an ASP.Net website project to a web application one. In the former, the profile is defined declaratively in web.config. However web application projects have trouble accessing the dynamically generated app_code DLL (as its not built by .Net until runtime). The workaround is to access the profile's properties thus:
ComplexProfileProperty _cpp = (ComplexProfileProperty)HttpContext.Current.Profile.GetPropertyValue("valuename");
Hth,
apologies if I've totally misread your question - hard to be certain without code examples :-)
I assume you've looked at the documentation - here and here and here.
This sounds like some errors I've encountered trying to access/set properties on an anonymous user. There are quite a few things that can't be done with anon. users.
Are there other errors related to Profiles/Membership? It could be a problem with the db tables or Application Id/User Id. Context.Request.AnonymousID does not necessarily reflect anything in the db, from what I've found debugging Profile issues.
If you're really stuck, you might want to try getting the source for the .Net Framework, and debugging into it.
One of the other developers at my company wrote a .NET 2.0 web site. He stores everything...solution, project, source...everything inside of "inetpub\AppName" (the IIS share). I have never seen this done before. In fact I'm kinda surprised the website loads up in a browser. Are there any disadvantages to doing this over say...storing your solution in the visual studio 2010 projects folder and then publishing the website to inetpub (security, speed, etc)? Also, Why does this work?
It works because the site would be compiled on the fly. This is bad from performance point of view (because the late compilation) and it's bad from security point of view (you're exposing your code more than necessary).
From MSDN
Because ASP.NET compiles your Web site on first user request, you can simply copy your application's source code to the production Web server. However, ASP.NET also provides precompilation options that allow you to compile your Web site before it has been deployed, or to compile it after it has been deployed but before a user requests it. Precompilation has several advantages
There's really no reason it shouldn't work, but it's generally considered a bad idea. Is he developing directly on the shared site? That's scary. Even if he isn't, that's putting a lot of files on a shared site that shouldn't be there. The server may be configured not to return them, but one shouldn't get comfortable relying on that.
Even on his local machine, it's bad practice. If for no other reason than it doesn't properly mimic the published site and makes for a bad place to test things.
There's nothing special about the Inetpub folder—it's just the default web server root by convention. Nothing about it will prevent IIS from displaying ASPX pages if it's also part of a solution (which is only referenced in the project file's XML). You can also point IIS to the project directory in the Visual Studio Projects folder.
Storing userdata on C: is usually bad practice (specially for a programmer).
Most of us have a data partition that contains just userdata which is backed-up frequently or use a source repository on another server.
If you're on a secure LAN and just developing by yourself there is really no problem putting the solution in InetPub. However if you use the same IIS to publish to the world i wouldn't recommend it. You never know who might get to your precious gems.
I'd say it's bad practice. Your entire code is at the mercy of the web server. If the server is hacked the code is a freebie reward.
Why is it better to store data inside an appSettings element (or inside a custom section) of a web.config file than to store it in a class?
One argument would be that by using custom sections we don’t have to recompile code when we change data, but that’s a weak argument, especially if we’re using Web Sites, which get recompiled automatically whenever code changes!
Thank you
Because you can change it on the fly and use it without regard to class structure. Your configuration can vary from each developers machine to staging to deployment environment by changing and maintaining a single file independently of the code, and you can take advantage of *.config masking with different areas of your site.
Hard coding anything configurable is a recipe for failure and it absolutely will bite you - this is just a matter of experience, if you don't believe it then you have but to wait a little while!
By putting settings into web.config, you have them all in a centralized location.
Also when deploying a web site, you might want to precompile it once. So you won't be able to change the source afterwards (without another recompilation).
It's not really a concern of just recompiling the code, it's more about re-deploying the code. Normally, you don't deploy code to the web server, you just deploy the binaries and aspx/html files. If you hard-code your config data in the code, you'll have to rebuild and redeploy the library or application to get the change up to the server, which is a lot more work than just updating the web.config.
Putting data in the web.config file also allows the same code to be run in different environments with different environment-dependent data. This can mean running the same website code in staging with a test database connection string and in the production environment with the production database connection string. Or it could mean allowing the developers to configure the data for their own tests without changing any code, as 'annakata' mentioned.
It's just a WHOLE lot easier to manage and update the settings.
If you're using Notepad to do your development and putting the code out on the server, I would agree that there is little benefit, but if you're using Visual Studio and you build your website and publish it, you're publishing the pre-compiled dlls and not just updating text source code (.cs or .vb files) on the server. So when it comes time to update a setting at that point, anything in the web.config can be updated by simply modifying the text file, where as with other changes, you have to re-compile t whole web site and publish it.
And from experience, that becomes tricky when taking over after other developers that weren't careful about ensuring everything needed to make a web site work is in source control. I'm now stuck with a web site where we can't update huge chunks of it because of (kindly putting it) non-standard practices in the past.
Being able to update something without re-publishing the site is a huge blessing in my situation, and you never know who the poor maintenance programmer will be that takes over on your code.
Be nice to him or her. Make it easy to make simple changes.