#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2013
    Posts
    2
    Rep Power
    0

    Question How can my API accept a posted file (not just JSON objects)?


    I've searched around but I think my problem is a little too specific to find a good answer without posting.

    I've been working on an API to prepare my site to be used by a mobile app. An API is new territory for me, so I used a PHP MVC API tutorial that I found (link: http :// net.tutsplus.com/ tutorials/ php/ creating-an-api-centric-web-application/ ) to start it off. I've removed all the inapplicable elements and have been able to successfully customize it for my own needs. Adapting the tutorial in to something useful for me has been easy.

    What isn't covered in this tutorial however, and what I unfortunately can not seem to figure out, is how a file can be posted to this type of API. I need the API to be able to accept image files along with the user's description of the image.

    Details on the API set up:

    The client side takes an app public key, an app private key, the user's credentials, a controller name, an action name and a set of parameters for the action. It encrypts the whole request in to one string using mcrypt and the app's private key. It then POSTs to the api url two things: the public key and the encrypted request.

    The API itself then reconciles the public key with it's private key on it's side, decrypts the encoded request using the apps stored private key, and if its decrypted succesfully begins taking the actions described in the request.

    Like I said, this is all been easy for me to use and customize when I only need it to work with JSON objects, but I am at a loss as to how to adjust this system to enable a file upload via the same process. Should the client side convert this to text, encrypt it and post it the same way? Or should the api itself accept file uploads via $_FILES?

    I have been stuck at this point. So any insight by anyone would be helpful. I will do my best to answer any questions you have.
  2. #2
  3. Transforming Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,122
    Rep Power
    9398
    The first question is whether the file upload needs to be encrypted. If not then multipart/form-data is fine and PHP can read the request normally: something in $_POST is the data, something in $_FILES is the upload.

    Otherwise you'd have to encrypt it, so you'd bundle and decrypt everything together, so you'd have to receive the raw file contents in memory rather than in $_FILES.
  4. #3
  5. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    It encrypts the whole request in to one string using mcrypt and the app's private key. It then POSTs to the api url two things: the public key and the encrypted request.
    Your explanation of the encryption method was somewhat difficult to follow so I may be misunderstanding, but posting the public key in plaintext with the encrypted contents defeats the purpose of using encryption because the public key is able to decrypt anything encrypted with the private key.

    Also, asymmetric encryption has a very low maximum payload size, too small to contain most image files. You will need to combine it with symmetric encryption in order to encrypt the whole payload, or just sign the request instead of encrypting it (if you only care about verifying the authenticity of the request and not protecting the payload itself from interception).

    Edit: Post 8000

    Comments on this post

    • Jacques1 disagrees
    Last edited by E-Oreo; June 4th, 2013 at 03:00 PM.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  6. #4
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    [edit by requinix] Don't write your own crypto protocol. [/edit]

    But seriously: Has it never occured to any of you that this whole idea might be a bit...wrong? I mean, how on earth can you advice somebody to "combine asymmetric and symmetric cryptography" when it's obvious that this person barely knows the difference between a public and a private key? Do you not care at all about the consequences of someone messing up their whole security?

    To be honest, I'm pretty disappointed by the advice I've seen lately. Instead of helping people to solve their problem, you merely fiddle with the technical details, regardless of how absurd the whole idea is.

    If somebody points a gun to their head, you don't help them by explaining how to properly pull the trigger.

    Comments on this post

    • requinix disagrees : chill
    Last edited by requinix; June 4th, 2013 at 05:32 PM. Reason: language
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  8. #5
  9. Transforming Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,122
    Rep Power
    9398
    I edited your post rather than wait for the abusive post report and warn you over it. More handles and less flying off them, deal?
    He's not inventing his own protocol, although he's got the keys mixed up a bit. He has data to send and needs to send it securely so it gets encrypted and transmitted. Are telling him not to "reinvent" the server/client architecture?

    Comments on this post

    • Jacques1 disagrees : Dude, if that post was already "abusive", you'd have to put your "sarcky" friend ManiacDan into jail.
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2013
    Posts
    2
    Rep Power
    0
    As it is now, the private key is used on the request side to hash the encryption of the request parameters. The apps public key and the encrypted request are then POSTed to the API. The apps private key is never transmitted.

    Then, the API uses the public key to consult a table and pull the apps private key, and uses it to decrypt the encrypted parameters.

    Is this not how a normal public/private key methodology works? Or did I just not describe it accurately in my first post? Like I said, this is my first time trying something like this.

    If this is a totally inappropriate use of this, please let me know.

    Thank you all.
  12. #7
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Hi,

    the home-made authentication scheme described in the tutorial isn't about public-key cryptography at all. It's the exact opposite: symmetric encryption. It uses the same key for encrypting and decrypting. In a public-key scheme, you'd have two different keys: one for encryption (the public key), one for decryption (the private key).

    What you call "public key" is no (cryptographic) key at all, because it's neither used for encryption nor for decryption. You may call it "API key" or "user ID" or whatever, but it's not a public key.

    Unfortunately, the author of the tutorial doesn't seem to know that himself, because he claims his scheme is "similar" to public-key authentication. That's nonsense. The whole purpose of public-key authentication is to not store the same secret key both on the server and the client's machine. The server only stores the public keys of its users, because if it gets compromised, you want to at least be sure that the attacker cannot grab all your user's keys.

    The scheme described in the tutorial is much, much less secure, because it involves storing the cleartext key on the server. If the service gets compromised, the attacker gets all API keys for free and can use them in any way he/she wants -- and you might not even know it. Long story short: This protocol is garbage. It's probably even worse than no security at all, because it gives you a false feeling of security. It makes promises it cannot hold.

    I'm not blaming you for not knowing this or getting the encryption stuff wrong or something. To the contrary! We should realize that we're developers, not cryptographers. As such, we should never invent our own protocol -- or use one invented by some other person somewhere on the Internet.

    Cryptography is an expert topic. We should leave it to the cryptographers, just like we leave brain surgeries to actual doctors. Designing a security protocol is one of the most difficult tasks in the IT. Even professional cryptographers constantly screw up trying to do it, and the chances of getting it right as a layman are effectively zero. Many people have tried it, and they all have failed, leaving their (and other people's) precious data open to anyone able to exploit the security holes.

    The conclusion we should draw from this is that we should always use established, solid, well-known and well-tested protocols, which have proven themselves in reality over a course of many years. Only then can we be confident that they (probably) work.

    I know this may be disappointing and boring, but that's how it is. Part of what makes a good programmer is that he/she is able to choose the right tool for the job. A home-made authentication scheme you found somewhere on the Internet isn't the right tool. What you want is established protocols like HTTPS, SSH etc.

    For example, one established way of authentication is HTTPS with client certificates.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo