Customer Portal

Get Involved. Join the Conversation.

Topic

    Bastiaan van der Kooij
    Which security checks are done for the $_FILES array
    Topic posted May 25, 2016 by Bastiaan van der KooijGold Crown: 30,000+ Points, last edited May 25, 2016 
    120 Views, 6 Comments
    Title:
    Which security checks are done for the $_FILES array
    Content:

    I was wondering what default security checks are performed on any files that are uploaded via POST. Since I know that the $_POST array is also altered for security reasons I presume that the same goes for the $_FILES array. That would safe me from creating security checks that are already in place ...

    I am not using any of the existing widgets / models, everything is custom...

    Version:
    November 2015

    Comment

     

    • Scott Harwell

      Hi Bastiaan,

      By alterations to the POST array, are you referring to the security tokens and such that are appended through the framework to prevent submission abuse?  Or, do you mean some alteration after the post has occurred?  

      I'm speculating in by answer below as I think this is a question that only Prod Dev can answer with certainty, but I think the answer is there are no "security checks" on this array..

      I doubt that FILES would be subject to similar changes because the files array would only exist if a successful post had occurred.  Uploaded files in the FILES array exist in temporary locations after post so that the application can save them accordingly through events that happen in the framework once the record is ready to be saved (moved to the attachments/file server).  You're likely accessing the array before the files are saved (attached) to a given record, and there are security checks, such as virus scanning and extension validation when that occurs.  I believe that the bits are also scanned inbound to Oracle's data centers by their firewalls as another precaution (the data would be decrypted at the load balancer and then scanned as it makes its way from the LB to the web server(s).  But, again, none of that would "alter" the FILES array unless there was a flag for a virus or something, but I'm not sure if that's what you're talking about here.

      What security measures are you trying to implement that aren't built into the product already?

    • Bastiaan van der Kooij

      hey Scott,

      the $_POST array is stripped of any html, before anything kicks in that you can modify as a user, hence my question if something similar happens to the $_FILES array as well.

      I am not dealing with anything from the framework like connect for PHP, I am custom uploading a file and storing it in the assets folder. 

      The security checks you're referring to in the datacenters, does that happen before the $_FILES array is available, or does that happen only when you use that file to create an attachment to any object? (since then I would bypass that security).

      Some securitychecks might be : Virus, checking if extension is actually also in the file header etc...

      Bastiaan

    • Scott Harwell

      Hi Bastiaan,

      I was unaware of any alteration to the POST array, especially removing HTML since that's something that you would want to store if using a WYSIWYG editor for threads or HTML formatted text.  Perhaps that is for a certain field...that's interesting that you're seeing that.  But, not really part of the question, so we won't go down that rabbit hole.

      So, just to clarify the process, you post a file attachment to a controller, check the file array for file existence, move the file from tmp to assets, and then use it there?  I take it that this is for a batch integration of some sort or a desire to automate making files available for download over the Internet?

      I'm not sure what (if any) active checks are performed at the application level since the file never really would hit any screening for extension type if this were the process.  You're using PHP and the file system to move the file around after a post, so the application code is likely circumvented almost entirely once the post happens.  But, I'm sure that Oracle's virus scan would hit the file at rest in assets and likely tmp, and likely in transit as I mentioned earlier, neither of which you could (or should) be able to circumvent.  That would happen regardless of extension type.  Otherwise, I don't see how or why the array would be altered as it would probably break the expectations for how PHP interacts with posted files if that array was altered.

    • Erica (Leep) Anderson

      Just checking in here...did Scott's response help you solve this issue, Bastiaan? Or are you still having this issue? Please let us know!
       

      Thanks,
      Erica, Community Manager

    • Bastiaan van der Kooij

      hey Scott,

      yeah both the regular $_POST array and the CI array are altered by html_strip_entities (or similar).

      The $_FILES array also seems to be altered in the sense that it is reordered (which is actually nice) similar to the function described here;
      http://php.net/manual/en/reserved.variables.files.php#109958

      That led me to think what else is going on. However I just do any other checks myself, even if it is done twice.. 

      Thanks for your thoughts!
      Bastiaan

    • Scott Harwell

      Hey Bastiaan,

      Not to belabor the $_POST topic, but now I'm curious to dive into that subject more as this seems like a particular use case and not global behavior (or at least, it shouldn't be in my opinion), but I don't think that I have ever tested any random text field being stripped of HTML content on CP post regardless of field context.  If I have a custom controller where I want HTML data to be posted, and I capture and output that array right after post or the base Rnt framework collects the post data, then the array should data should exist as it was at post time (including HTML tags) as the router and the controller would be the only framework classes that have parsed the data yet.  My custom controller (or the code igniter case framework) would not have passed the data to other PHP methods (through models, helpers) for processing yet (though one can tell CodeIgniter to parse through an XSS filter at post time, but that could lead to a lot of false positives).  I'm not aware if Oracle has altered the base framework to perform the strip_tags (or similar) method at post time.  

      That technical approach would remove the option to submit any HTML-based content from the web to CP, which seems odd to me.  I guess the alternative could be to push and HTML text field through REST or SOAP APIs using AJAX, but that doesn't make sense as HTML content, like threads, is paramount in the application and it doesn't make sense that there would be a a pre-processor to scan all post fields to remove HTML content on form submit.  If that does happen, it would seem that the best place would be a model post-submit which can perform the data alteration or validation before save, not after post.  Ultimately, a text field should be able to store HTML content and a blanket process to remove HTML tags doesn't seem right.  What if you wanted to store XML or text that was marked up with custom tagging?  Again, I don't know what the technical or business justification for preventing all CP posts from doing that would be, which is why I find this so odd.

      I just ran a few tests on my end through a custom controller and my HTML tags were not removed, but I wouldn't call this an extensive test as I just tested some basic tags.  And, for some reason, my demo environment is acting up right now...but I will test again when it comes back it.  So, just to make sure that I am replicating your test, you have a custom controller that you're posting to and as soon as you examine the $_POST array after submission, your content is altered?  Is there a difference in behavior if some tags are missing (i.e. <b> tags are allowed but structural tags like <html> and <body> are not)?

      I'm sure that if you're seeing this issue, then it's just as odd to you as it is to me.  Maybe there's a work around for you...or we can at least identify how/why this is happening for others that stumble upon the thread.  smiley