I'm looking for a way to increase security on some older web apps. They currently have their connection strings saved in plain text in an include.asp file. Ideally I was thinking of moving these to a web.config file and encrypting this using aspnet_regiis.exe, but this does not work for Classic ASP.
I've had a look around the internet but cannot find anything that seems to fit this specifically, has anyone run into the same issue before?
The best way to protect your include.asp is to use anonymous authentication on the site and be sure to set the NTLM security of that file so that it can only be read by the user used by IIS.
If that is not possible you can obfuscate the string in a number of ways but almost none will be very secure, so you can avoid these strings being seen by the casual nosy user but not to a hacker.
you can use your own crypt and decrypt function, but they will be visible themselves in the .asp files, see here and here for examples
you can use an external crypt and encrypt tool that is run from your .asp like this (i use this to run a Ruby script and get the results, replace the command executed by yours)
set objWShell = CreateObject("WScript.Shell")
set objCmd = objWShell.Exec("cmd.exe /c c:\Ruby193\bin\ruby.exe d:\inetpub\site\appl\RMW\import\import.rb")
result = objCmd.StdOut.Readall()
errors = objCmd.STDERR.Readall()
set objCmd = nothing
set objWShell = nothing
You could use Windows Script Encoder if your OS supports it, see
Related
I need to create a RSA container, export it and use it on a private machine and and on a machine that is part of a domain.
Why - encrypting web.config file of my ASP.NET app, so that I am able to run it on these machines. Solution to this would be to just not share the web.config file, encrypt them on each o the machines separately, but that would lead to duplicity and every downside that comes with that.
I was following this walkthrough. And got stuck at adding access rights to the key.
My question is: Is this even possible?
I was thinking of something like creating the key on the domain machine and than using a VPN/"run program as" to run it as the domain user. While trying this, I ran into some issues, but I did not give it enough time.
Is there another / better way? Help highly appreciated.
I have encrypted my ASP File. But when i run it in browser it fails. How to execute that asp file so that my application could run ?
how to decrypt it, it is encrypted using a tool , how do I decrypt it while execution ? I don't want that anybody whom I give that file , sees the code of the file , but could only execute it and use it.
Ah, I think I understand:
ASPEncrypt is a component you can use to encrypt files using ASP or ASP.NET. It is NOT a tool to encrypt your ASP(.NET) source code files with.
You're looking for something like Microsoft script encoder (I don't know if it's still available), you want your sourcecode to be unreadable right?
There are tools that claim to do this, but there isn't one I know of that can't be reversed. So it's only a small obstacle if someone really wants to get their hands on your code.
Here are some more tools that claim to do this.
I hope one of them suits your needs.
I had seen the answers of the questions related to mine .But still I am not sure how to store the user information taken from Qt dialogue box on file and then encrypt it ,so that no one else can read it .The other thing is that how to match the password and user name which is pre-specified in the file I had encrypted earlier..
if i understand you correctly, you just want to make an application that asks for authentication at application start-up, correct?
If that is the case, it is easy. The basic steps are as follows.
Keep the username and password in a file (since Unix does not have a registry). The file does not need to be encrypted at all (plain text will do). You can use xml for this. The data (text) in the xml file however that you write (the data... not the tags) should be written such that the strings that you write into the file are encrypted using a hash. Just look up hashing in C++ (SHA, MD5, etc). The decription/encrytion key can be hard coded in you application.
Then for the application logic. The first thing you show the user is the login window. If they fail loop it or exit application. Basically only when correct authentication info is provided you kill the login windows and kick-start the main application window.
Perhaps you should take a look at the QCA examples.
They have some nice examples of how-to use crypto in similar situations.
QCA is not standard in Qt but can be added on all platforms.
I've collected a (hopefully useful) summary of the ways I've researched to accomplish the subject of this post, as well as the problems I have with them. Please tell me if you've found other ways you like better, especially if they resolve the problems that the methods I mention do not.
Leave connection strings in web.config and use XDT/msdeploy transformation to replace them with settings according to my active build configuration (for example, a web.PublicTest.config file). My problem with this is I merge and bury a few server-specific settings into an otherwise globally identical file with many configuration elements. Additionally, I cannot share connection string definitions among multiple peer-level applications.
Specify a configSource="DeveloperLocalConnectionStrings.config" value for connection strings in web.config, and XDT transform this value to point to one of the multiple environment-specific files in my code-base. My problem with this is I send passwords for all my environments to all destinations (in addition to SVN, of course) and have unused config sections sitting on servers waiting to be accidentally used.
Specific connection strings in the machine.config file rather than web.config. Problem: who the heck expects to find connection strings in the machine.config, and the probability of surprise name collisions as a result is high.
Specify a configSource="LocalConnectionStrings.config", do not transform the value, and edit the project xml to exclude deployment of the connection string config. http://msdn.microsoft.com/en-us/library/ee942158.aspx#can_i_exclude_specific_files_or_folders_from_deployment - It's the best solution I've found to address my needs for a proprietary (non-distributed) web application, but I'm paranoid another team member will come one day and copy the production site to test for some reason, and voila! Production database is now being modified during UAT. (Update: I've found I can't use one-click publish in this scenario, only msdeploy command line with the -skip parameter. Excluding a file as above is the same as setting it to "None" compile action instead of "Content", and results in the package deleting it from the deployment target.)
Wire the deployment package up to prompt for a connection string if it isn't already set (I don't know how to do this yet but I understand it is possible). This will have similar results to #4 above.
Specify a configSource="..\ConnectionStrings.config". Would be great for my needs, since I could share the config among the apps I choose, and there would be nothing machine-specific in my application directory. Unfortunately parent paths are not allowed in this attribute (like they are for 'appSettings file=""' - note also that you can spiffily use file= inside a configSource= reference).
p.s. some of these solutions are discussed here: ASP.Net configuration file -> Connection strings for multiple developers and deployment servers
When using SQL Server, you can also use Integrated Security / SSPI and add the WebServer Computer Login to the Sql Server.
That way you dont have to expose anything in the web.config and you can grant roles to that login like you would to any other DB user.
Though you have to understand the implications and security considerations to be taken, because any malicious code executed as THAT machine will have access to the Sql Server.
with regards
Ole
Use the hostname as key for the connectionstring, that way you can choose the datasource automagically. Make sure the choosing routine is not buggy (change hostname - test!)...
Don't put it in the web.config, write an ini file, that way there is no XML encoding.
Encrypt the password therein, with private/public key (RSA/PGP). Don't ever use cleartext, or a symmetric key, which is just as bad.
Check my following blog post: Protecting asp.net machine keys and connection strings
If you do use Quandary's answer, use a key that's not in the site's folder, just like asp.net does with protected config sections.
We manually approve changes to the web.config that go into staging/production. We use integrated instead of username based where possible, but an option we've used in the later case is to just have placeholders for the username/passwords in SVN.
We've used separate config files in the past, but we have run into other type of issues with web.config modifications, so we have been locking it in a single file lately.
Solution:
It turns out I wasn't checking the path that it was looking up, quite silly of me. Once I tracked that problem down and corrected the offending path, the reading worked just fine. Still baffled at the MSSQL issue, since the articles average less than 10 000 bytes.
Clarification:
I am unsure if some of you are under the impression that the file I am trying to read is on my local machine. It resides on the web, on the same server as the script that is accessing it. Just in a different directory.
I wrote an online help desk application that includes articles. One problem I have run into
is some of the articles are too long, and get truncated when I put them into my MSSQL database. I tried using TEXT and VARCHAR(MAX) as the data type, but it would still get truncated.
So I decided that I would put the articles that are too long into a text file, and have my application read the text file from there. I got this code working in my development environment, but it does not work live:
Dim output As String = String.Empty
Try
Dim theArticle As gsClassroom = classArticles(iterate)
If theArticle.Body.StartsWith("/docs/") Then
Dim oReader As IO.StreamReader = Nothing
Try
oReader = New IO.StreamReader(Server.MapPath(String.Format("/dev{0}", theArticle.Body)))
Catch ex As Exception
output = String.Format("{0}<br /><br />{1}", ex.Message, "internal")
Finally
oReader.Close()
oReader.Dispose()
oReader = Nothing
End Try
Else
output = theArticle.Body
End If
Catch ex As Exception
output = String.Format("{0}<br /><br />{1}", ex.Message, "external")
End Try
Response.Output.WriteLine(output)
At first, I thought it was because I did not change the /dev path prefix to /hlpdsk. But even after I changed it, it bombed out. What am I doing wrong?
The first thing that enters my mind on these sorts of issues is permissions settings on your production environment won't allow you to access that directory.
I know you want to solve the issue of reading this text file, but I would suggest that you go back to reading the text from the sql server table with Varchar(MAX).
Please note that when text is larger than a few KB it splits it down to several results. So when reading you would have to read from datareader and write to a string builder. When done then you would have the full content in the string builder.
As for the file reading don't do it. It would have a lot of file permission issues in the server environment.
What kind of helpdesk articles are more than 2^31-1 bytes long? (The limit of varchar(max))
An article that long would take so long to load that people would assume the web site is broken and give up. Wouldn't it?
The reason it failed is permissions, just as Matthew says. When you develop in VS, you typically run using the integrated Visual Studio web server. When running this web server, it's running under the permissions of your logged-in account, which means you've got access to pretty much everything on your local PC.
When you deploy to production, you're running in IIS, and the security permissions are that of the Application Pool that your app happens to be running in. By default, an AppPool runs under the NetworkService account, which means it has minimal access to local resources on your PC.
You can elevate the permissions of the AppPool, but this is a bad practice and a security risk. A much better approach, as has already been stated, is to properly use the data types available in SQL Server to store your data.