On Wed, Mar 25, 2009 at 2:18 PM, Walter Bright <[email protected]> wrote: > > Here's the scenario I'm concerned about. Let's say you set up a website that > instead of supporting javascript, supports D used as a scripting language. > The site thus must run the D compiler on the source code. When it executes > the resulting code, that execution presumably will run in a "sandbox" at a > low privilege level. > > But the compiler itself will be part of the server software, and may run at > a higher privilege. The import feature could possible read any file in the > system, inserting it into the executable being built. The running executable > could then supply this information to the attacker, even though it is > sandboxed. > > This is why even using the import file feature must be explicitly enabled by > a compiler switch, and which directories it can read must also be explicitly > set with a compiler switch. Presumably, it's a lot easier for the server > software to control the compiler switches than to parse the D code looking > for obfuscated file imports. >
One, you do not use Javascript as a server-side scripting language. That task is usually relegated to (shiver) PHP, Ruby, Python, Java or the like. Javascript, as far as I know, only has a place in web programming in client-side (browser-side) scripting. The only thing you can do from the client is maybe munge some POST data, and then that's a logic error on the part of your server script, not anything to do with the language. Two, if you did replace your server-side scripting language with something like D, there are no more or fewer security holes than with any other server-side scripting language. The entire point of server-side scripts is that they are invisible to the clients, and the clients never see, modify, or upload server-side scripts of their own. It's not possible to put a malicious file import in the D server page unless you actually have access to the server, and if an attacker does have that kind of access, D is no more or less secure than any other server-side language. They'd all be vulnerable. The attacker could just change the server's compiler flags to change the import directory anyway. I understand your desire to restrict the use of import expressions, but your example just does not add up.
