27 ms·

40 or so lines? I'm sorry, what? https://github.com/julien-c/Tampon/tree/master/api https://github.com/julien-c/Tampon/tree/master/api Also, I don't think this

by sync 14y ago

40 or so lines? I'm sorry, what? https://github.com/julien-c/Tampon/tree/master/api https://github.com/julien-c/Tampon/tree/master/api Also, I don't think this counts as security: if (strlen($id) == 24) { // Looks like a valid MongoId Edit: this looks bad too: $post = json_decode(file_get_contents('php://input'), true);

julien_c 14y ago
Wait... why would it be bad?
- rhl 14y ago
  NoSQL injection ? If such a thing exists ?
NathanKP 14y ago
There is nothing wrong with either of those two lines of code provided that they are not the only layers of security. Checking to see if an ID is of the right length is a good way to filter out miss formated ID's early. And the JSON decoding statement is a pretty standard way to get the JSON body out of the request and into an associative array. Of course you will need to validate that it has the right format now, probably using JSON Schema or something similar.
- sync 14y ago
  Looks to me like they just insert the JSON body directly into Mongo without any sort of further validation: $m->tampon->queue->insert($post);
  - NathanKP 14y ago
    Ooh yeah that isn't very good. They should really be using a JSON schema validation library to verify that someone isn't storing extra fields in the database, and that all the fields are of the right format and type.
    - julien_c 14y ago
      You're right. But the worst thing that can happen is someone POSTs large fake objects and tries to flood my server's hard drive. Which, given the max size of a POST's data will take quite some time :) The API only allows querying posts on the current user (with now user input) so there's no risk of "NoSQL injection": https://github.com/julien-c/Tampon/blob/master/api/posts.php https://github.com/julien-c/Tampon/blob/master/api/posts.php
      - NathanKP 14y ago
        I see. I would still recommend JSON schema, though. It is great for debugging and ideal if you plan to open the API up to third party developers, because it makes it easy to ensure that all NoSQL data adheres to a proper schema, and it also provides meaningful error messages if a third party developer accidentally sends badly structured JSON to your service, or even if you accidentally send badly structured JSON to your service due to a front end bug. I use this JSON Schema validator with great success: http://packagist.org/packages/hasbridge/json-schema-validator http://packagist.org/packages/hasbridge/json-schema-validato...

by sync 14y ago

julien_c 14y ago

Wait... why would it be bad?

rhl 14y ago
NoSQL injection ? If such a thing exists ?

NathanKP 14y ago

There is nothing wrong with either of those two lines of code provided that they are not the only layers of security. Checking to see if an ID is of the right length is a good way to filter out miss formated ID's early. And the JSON decoding statement is a pretty standard way to get the JSON body out of the request and into an associative array. Of course you will need to validate that it has the right format now, probably using JSON Schema or something similar.

sync 14y ago
Looks to me like they just insert the JSON body directly into Mongo without any sort of further validation: $m->tampon->queue->insert($post);
- NathanKP 14y ago
  Ooh yeah that isn't very good. They should really be using a JSON schema validation library to verify that someone isn't storing extra fields in the database, and that all the fields are of the right format and type.
  - julien_c 14y ago
    You're right. But the worst thing that can happen is someone POSTs large fake objects and tries to flood my server's hard drive. Which, given the max size of a POST's data will take quite some time :) The API only allows querying posts on the current user (with now user input) so there's no risk of "NoSQL injection": https://github.com/julien-c/Tampon/blob/master/api/posts.php https://github.com/julien-c/Tampon/blob/master/api/posts.php
    - NathanKP 14y ago
      I see. I would still recommend JSON schema, though. It is great for debugging and ideal if you plan to open the API up to third party developers, because it makes it easy to ensure that all NoSQL data adheres to a proper schema, and it also provides meaningful error messages if a third party developer accidentally sends badly structured JSON to your service, or even if you accidentally send badly structured JSON to your service due to a front end bug. I use this JSON Schema validator with great success: http://packagist.org/packages/hasbridge/json-schema-validator http://packagist.org/packages/hasbridge/json-schema-validato...