Web Q&A: Scripting Security

Article
10/23/2019

Web Q&A

Scripting Security

Edited by Nancy Michell

Q I'm trying to use the managed classes for SQLXML2 from a Web Service. I find when I use "Trusted_Connection=Yes" in my connection setting, Windows NT® security is used, but apparently I'm connected as the local machine account, not the logged-on user account. When attempting to execute my query, I get "Login failed for user 'MyLAN\MyMachine1$'" (my machine name is MyMachine1). I'd like it to use my user account (MyLAN\MyAccountName) instead.

A If your Web Service process is running under the local machine account, you can change it by modifying the Web publishing service in the Services MMC to log in as your own account. This setting is under the Log On tab. Note that if you change the logon setting for the WWW service, you will also need to change the logon settings for the Microsoft® Internet Information Services (IIS) Admin service and the SMTP service if it is running. Now every request will be authenticated as you. If you want to authenticate using the credentials of the person making the request, you should add the following line to your web.config file under the <system.web> tag:

<identity impersonate="true" />

<identity impersonate="true" />

In addition to adding Trusted_Connection=Yes to the connection string, you should add Integrated Security=SSPI. Also, remove anonymous login to your application.

Q Aside from cross-site scripting, what top security issues should I be aware of when scripting for the Web?

A The biggest thing that you need to look out for is this: do not assume that any data that comes from the client is well-formed. Cross-site-scripting, SQL injection, and misuse of the JScript® or VBScript eval method are all potential attack points when hostile clients pass in bad data.

If you use eval (or execute, or executeGlobal in VBScript) on your server-side page, then be particularly careful. Not only might you have a security hole, but you probably have a performance problem as well.

Q If I create an InternetExplorer.Application from within a CScript process using JScript, will it be limited by the current Web security restrictions in effect? Is there a way to create the equivalent of an HTML application (HTA), with similar security settings?

A This is only possible if you put the script inside the HTML page. You can put event handlers in the CScript for HTML elements and the event handlers will run in the security context of Windows Script Host (WSH).

Q Can I access a COM object in a DLL from JScript by providing the full path to the DLL, but without registering the DLL first? This is for a command-line tool running under cscript.exe; the security implications that this would have for running under Microsoft Internet Explorer are irrelevant here.

A The only way the script engine loads objects is via the registry. Even if there were no security concerns, the problem is more fundamental. Suppose there were two, three, or even a hundred objects implemented in that DLL. How would you tell the script engine which one to use? Well, you'd provide a class name, and then you're back where you started, with the loader looking up the class name in the registry.

COM could have been designed to take a DLL-path-and-class-name pair rather than always looking it up in the registry, but it wasn't. Of course you are free to write your own loader that creates the class factory, and so on, without hitting the registry.

Q I have been asked to write an HTML page that uses client-side JScript to walk the directory that the file is in using the FileScriptingObject. I have the same page in ASP that does this from the server side, but I want users to be able to just point to a share and open the local .htm page and have it work. I copied the code from my ASP page to my new HTML page, but I get script errors saying it can't create the FileScriptingObject. Is there a security issue here that is stopping me?

A Enable "Script ActiveX Controls not marked safe for scripting" in Internet Explorer (or, preferably, set it to "Prompt"). You should do this only for the Intranet zone, and (if you really want to) for the Trusted Sites zone, never for the Internet or Restricted zones.

Q How can I tell if a JScript file is secure or if it will cause damage?

A The JScript language itself is secure because it can't do anything (as far as accessing the operating system, that is); everything "bad" must be done via ActiveX® controls.

If the JScript engine is hosted in a trusted host (such as WSH), then you can invoke all sorts of unsafe ActiveX objects via the new ActiveXObject or GetObject commands. If the host object model is unsafe, you can do nasty things there, too.

If the script is invoked in an untrusted host, such as Internet Explorer, then bad controls can't be created. Of course, this is a simplification; Internet Explorer will allow unsafe controls in accordance with the user's security policy.

So you should always look for ActiveXObject and GetObject calls if you are running JScript files in a trusted host. Also look for eval and Function as they could be used to indirectly call the two ActiveX methods.

Security also depends on whether the files are WSH files, include files for a server-side ASP application, include files for a client-side HTML application, and so forth. The security considerations are different for each of these files.

The best way to approach the question is to ask yourself what it is you're trying to prevent. Secure code means essentially that it can't be used to hurt people when used properly. So, what is properly? If you're writing a file backup utility, then secure means no one who is not a backup operator can use it, not "it can't touch my file system"—obviously a backup program has to touch the file system. So determining whether your source code is good or bad is premature. What you need is a threat model.

Compare two programs, say Internet Explorer and FDISK. FDISK is extremely dangerous—it can destroy your disk—but is there any way it could possibly be called by someone who is hostile? If not, then who cares how dangerous it is? Internet Explorer, on the other hand, downloads and runs potentially hostile script code all the time—there is a very real possibility that the Internet Explorer object model will be called with hostile code, so the Internet Explorer object model must be very safe.

The fact that your program is written in script is largely irrelevant right now—what you need to ask is "can hostile people ever call this program? Can hostile people ever provide bad data to this program?" and so on. Once you know how the evildoers can attack you, then you can start looking for holes.

Remember who and what you're securing against and don't go overboard. Lately there have been a lot of panicky people thinking "If the user does this bad thing, then bad things happen." You can't prevent the user from intentionally damaging his own system, but it's safe to assume the user is not hostile towards himself!

Q I'm building a Web page that needs to retrieve information from a text file. Currently, I'm using FileSystemObject in JScript, which opens and reads the file correctly. However, I always get a warning message saying "An ActiveX control on this page might be unsafe to interact with other parts of the page."

I realize that there may be security hazards if people use the FileSystemObject to write to files, or at least there is the possibility of damaging files on the user's computer, but all I'm doing is reading from a file. The message comes up at the line where the FileSystemObject is created:

fileSysObj = new ActiveXObject("Scripting.FileSystemObject");

Is there any way I can get rid of the warning?

A Although it may not seem obvious at first, reading files is also a huge security problem. Would you like a random Web page mailing your personal e-mails, documents, or database items to a hacker? How would you like it if you went to a Web page and it uploaded the contents of your hard disk to the evil hacker's site?

Even if that wasn't an issue, the ActiveX technology doesn't have the fine-grained control you need for this—you either run the control or you don't. Microsoft .NET addresses this with very fine-grained security permissions.

So the dialog box won't go away. Hopefully your customers all say "No!" to this dialog, unless it is on an intranet. Never say Yes to this dialog on the Web, in e-mail, or even on an intranet, unless you know why you need that control and who wrote it.

In case you were wondering, you should never ask a customer to say "Yes" to that dialog on the Web. That's a truly bad practice. If your users wanted to avoid all such messages, they could turn off Internet Explorer security, but that would be foolish.

Q I have a question about security using updategrams. I have secured the virtual directory using Windows integrated security and I'm using that to authenticate against SQL Server™. Are there problems with this approach that would expose the system to unauthorized access, denial of service, or other security risks?

A Requiring Windows NT Lan Manager authentication and secure sockets layer will make updategrams very secure. As with any application that uses SQL Server, you want to give the authenticated users the minimum SQL Server rights they require to execute the updategrams they submit. The POST size limit should be set to a reasonable number—just slightly larger than the largest legitimate updategram expected.

There is a vroot option that allows only updategrams. Make sure the option "Allow sql=... or template=... URL queries" is off. This prevents users from posting arbitrary SQL and template queries. Turning this option off will enable "Allow posted updategrams." When this option is turned on, queries in templates (posted either through HTTP GET or POST) are ignored.

For example, if you execute the following SQL query

https://localhost/nwind?template=
<root+xmlns:sql="urn:schemas-microsoft-com:xml-sql">
  <sql:query>
    select+*+from+employees+for+xml+auto
  </sql:query></root>

the result is this:

<root xmlns:sql="urn:schemas-microsoft-com:xml-sql">
  <?MSSQLError HResult="0x8000ffff"
    Source="Microsoft XML Extensions to SQL Server" 
    Description="Queries not allowed in updategram only template"
  ?>
</root>

Q I have a question regarding the security of the XML DOM in Internet Explorer. In my application, I store all customer data in the DOM. While the data that is presented to the UI is based on the user's role and authorization, I'm afraid a user might read the DOM cache, or access the DOM itself, and reveal its contents. Will encryption help? I want to reduce round-trips to the server, so I'm sending a large XML document to the client and I'm depending on the client to process the responses. I have almost 65,000 users and a million rows in SQL Server, so I really want to offload some work.

A First, forget about encryption; it won't help you here. You already have basic encryption in the CryptoAPI, but there is no way you can use it to achieve what you want.

If you're just ensuring that the user does not get to the data in the DOM and that only you can access it through XSLT, the solution will be easy. You can write your own simple ActiveX control that hides inside DOM objects for both data and all the XSLTs you need. Such an object would have a single method that applies the stylesheet to the data with specific user credentials. In this case all you have to worry about is memory dump attacks.

But, if you really need to hide the data from the user, how would you prevent someone from impersonating your client or interception on the socket layer? And why does this decrease the load on the server? You cannot change the user without accessing the server, so what's the advantage?

Sometimes it's not the user, but malicious code that you must protect against. If the malicious code is trusted and runs as an executable, you cannot protect against it. But if your question is limited to scripts in other Internet Explorer windows, then a number of safe locks are already in place. For example, Internet Explorer does not allow scripting across domains (accessing HTML pages in another domain).

As mentioned earlier, a serious security review of your project will show exactly what you need, what data you need to protect and against whom, what types of attacks are possible, and so on.

Got a question? Send questions and comments to WebQA@microsoft.com.

Thanks to the following Microsoft developers for their technical expertise: Harsha Bennur, Srinivasa Burugapalli, Tim Edalatpour, Claudio Goralczuk, Dion Houston, Dirk Karis, Eric Lippert, Todd McKinney, Cornel Moiceanu, Jonathan Morrison, Eldar Musayev, Todd Pfleiger, Chris Shenar (Volt), Peter Torr, Roger Wolter, Steven Wort.

Share via

Additional resources