5 ms·

Ideally though, you should make sure that anything not part of your system, doesn't get passed through PHP. This will take away this common security risk, as we

Ideally though, you should make sure that anything not part of your system, doesn't get passed through PHP. This will take away this common security risk, as well as limit the overhead required to serve those files.

maratd 15y ago
> Ideally though, you should make sure that anything not part of your system, doesn't get passed through PHP. For you to upload a file to your system it has to pass through PHP. That's where the problem is. Once it's on your system, it can be executed by other means ... those means not necessarily being Apache or NGINX. By encoding the upload, you not only reduce the size, but also render it harmless.
- infinity 15y ago
  Just a thought: can we find some input, which will turn into a malicious script, when compressed or encoded by an algorithm and saved as a file on the server? The encoded file could contain something like <?php ... ?>. If the server could be tricked into parsing the encoded file for PHP, we are in trouble. I think about uploading an additional .htaccess, which will contain a directive to send .zip files to the PHP parser - of course this should never be possible. There are some encoder/decoder tools on the web, where it is possible to enter, for example, base64 encoded strings and get these decoded. It is often possible to enter base64 encoded JavaScript plus some closing tags or brackets to break out of the input field. When decoded, the JavaScript will be executed by the browser and we have found a cross-site scripting flaw.
  - maratd 15y ago
    > Just a thought: can we find some input, which will turn into a malicious script, when compressed or encoded by an algorithm and saved as a file on the server? This is not possible with gzip: http://www.gzip.org/zlib/rfc-gzip.html#file-format http://www.gzip.org/zlib/rfc-gzip.html#file-format I should mention that on top of this technique, I also rename all files uploaded to a random hash that is stored in a database. That hash is never revealed to the client. When the file is downloaded, the real name is provided from the database as the file name, while the source of the file is read from its true location. So even if an intruder were to upload a malicious file and somehow managed to bypass the encoding algorithm ... he wouldn't know where to find it. He would have to hack the database on top of everything just to find out where it is.

maratd 15y ago

> Ideally though, you should make sure that anything not part of your system, doesn't get passed through PHP. For you to upload a file to your system it has to pass through PHP. That's where the problem is. Once it's on your system, it can be executed by other means ... those means not necessarily being Apache or NGINX. By encoding the upload, you not only reduce the size, but also render it harmless.

infinity 15y ago
Just a thought: can we find some input, which will turn into a malicious script, when compressed or encoded by an algorithm and saved as a file on the server? The encoded file could contain something like <?php ... ?>. If the server could be tricked into parsing the encoded file for PHP, we are in trouble. I think about uploading an additional .htaccess, which will contain a directive to send .zip files to the PHP parser - of course this should never be possible. There are some encoder/decoder tools on the web, where it is possible to enter, for example, base64 encoded strings and get these decoded. It is often possible to enter base64 encoded JavaScript plus some closing tags or brackets to break out of the input field. When decoded, the JavaScript will be executed by the browser and we have found a cross-site scripting flaw.
- maratd 15y ago
  > Just a thought: can we find some input, which will turn into a malicious script, when compressed or encoded by an algorithm and saved as a file on the server? This is not possible with gzip: http://www.gzip.org/zlib/rfc-gzip.html#file-format http://www.gzip.org/zlib/rfc-gzip.html#file-format I should mention that on top of this technique, I also rename all files uploaded to a random hash that is stored in a database. That hash is never revealed to the client. When the file is downloaded, the real name is provided from the database as the file name, while the source of the file is read from its true location. So even if an intruder were to upload a malicious file and somehow managed to bypass the encoding algorithm ... he wouldn't know where to find it. He would have to hack the database on top of everything just to find out where it is.