PHP：安全方式保存并显示CodeMirror中的用户代码

Question

I'm setting up a simple web-based code editor using CodeMirror to help students learn basic HTML, CSS, and JavaScript.

I want the students to be able to save their code, so it is visible in a stand-alone browser window with its own link that can be shared with friends and family to show off their work (i.e. mydomain.com/users/their-username/test.html).

I currently have the following PHP, but I know my use of $content is not secure at all:

if ($_POST['type'] == 'save') {

  $content = stripslashes($_POST['code']);
  $username = addslashes(strip_tags($_POST['username']))); //i.e. markrummel
  $filename = addslashes(strip_tags($_POST['filename']))); //i.e. test, index
  $ext = addslashes(strip_tags($_POST['filetype']))); //i.e. html, css, js
  $path = '/users/' . $username . '/';
  $URL = $path . $filename . '.' . $ext;

  file_put_contents($URL, $content);

}

In most cases $content should be safe HTML, CSS, or JavaScript, like: <p>My name is Mark</p>, but I want to be prepared in case something malicious is put into the code editor to be saved.

Any suggestions on how I can securely save and display their code? Is there a way to quarantine/sandbox each user's folder from other user folders and the rest of the website?

Maybe there is no secure way to do this and I shouldn't allow anyone I don't trust to save code to my server, but if there is a safe way to do this...that would be great for this project! If not, I'll figure something else out.

Thank you for any help or insight you can offer! -Mark

Answer 1

addslashes and stripslashes do nothing for you here at all. I'm not sure what you are trying to do with them but slashing a string is not a useful form of encoding for filename handling or really any context you are likely to meet in a webapp.

strip_tags is also of no use for anything to do with filenames; it removes HTML from a string (but even then not really in a good enough way to use as a guard properly against HTML injection).

$URL = $path . $filename . '.' . $ext;
file_put_contents($URL, $content);

Yeah, this is seriously unsafe. By putting .. segments in the username or filename, an attacker can store files outside the root path. With complete control of the filename including extension that can include executable files like .php or other sensitive files like .htaccess. (Even if $ext were limited to known-good values, depending on OS your server is running under, it may also be possible to evade that extension appending.)

Whilst it is possible to sanitise filenames by limiting the characters that can be used in them, it's harder than you think to make that watertight when you might be running on eg. a Windows server. It's almost always better to generate filenames yourself (eg using a unique integer ID instead of an attacker-supplied filename) for storage on your local filesystem. You can always use rewrites to make the files appear to have a different address.

In most cases $content should be safe HTML, CSS, or JavaScript

Are you sure that's safe then?

If you serve some user-supplied scripting from inside your domain, it can control everything any of your users does within the site. It could override or fake any user-level security controls you have, upload files under other users' names and so on.

You can try to sanitise submitted HTML to make it use only safe tags, but that's hard to get right, and of no use if you want to permit users to run CSS/JS!

Is there a way to quarantine/sandbox each user's folder from other user folders and the rest of the website?

Yes. Serve each area from a different hostname. eg. put the main site on http://www.example.com/ with sandboxes at http://tom.users.example.com/, http://dick.users.example.com/ and so on.

This prevents direct cross-site scripting. To ensure sandbox sites cannot read cookies from the main site, make sure it is not also running on example.com (redirect it to www.example.com).

This isn't quite a complete sandbox. If you need to ensure sandbox sites cannot write cookies to other sites (potentially breaking them by stopping their own cookies working then you have no choice but to run each sandbox in its own full domain. And if you have to guard against Java plugin URL connections, each sandbox needs its own IP address. This gets costly quick! But these are less serious attacks.