4 ms·

It's worse than that, his PHP scripts make cURL calls to a local nodejs server which then exec() the ipfs commmands.

toomuchtodo 11y ago
Ipfs exposes a JSON API locally. Not sure why the author didn't just use a JavaScript front end making calls to the local API. https://ipfs.io/docs/api/ https://ipfs.io/docs/api/ EDIT: I'd encourage the HN community to look past the technical merits of the code, and focus on the idea presented (and even perhaps fork and contribute back an improved version).
- eis 11y ago
  Hm what prevents some malicious website from pinning unwanted content on a visitors machine?
  - Natanael_L 11y ago
    The visitor needs to chose to run IPFS and cache it
    - eis 11y ago
      He just needs to happen to have IPFS running. Any website can make a request to localhost via Javascript or even without. Scenario: Attacker sends you harmless looking link to a page that contains some invisible JS that sends a request to localhost and pins kiddypon on your IPFS node. Attacker then sends the police to you.
      - ossreality 11y ago
        um, cross origin blocking has been a thing for... like a really really long time now.
      - mappum 11y ago
        The IPFS API isn't exposed like that, there is actually a whitelist for hashes that can access the API (the IPFS webui is in the whitelist by default), and hashes that are blocked will get a 403.
- mrmondo 11y ago
  As you suggest, looking past the code quality / implementation choices I believe the idea if solid and it is a creative use of IPFS to attempt to 'solve' a real world problem, I'm excited to see more projects like this.
mweibel 11y ago
yep, and doesn't use prepared statements for DB queries..
- PlzSnow 11y ago
  There's nothing wrong nor insecure about choosing not to use prepared statements. There does seem to be a very conservative/cargo cult streak amongst some tech people that there are only pure ways to do things. For example there is nothing wrong with building a SQL statement as a string and passing it to a database. If it's programmed correctly then it is exactly as secure as a prepared statement.
  - kevan 11y ago
    > If it's programmed correctly then it is exactly as secure as a prepared statement. It's really easy to program them incorrectly, and as a result the approach is less secure than just using prepared statements.
  - mweibel 11y ago
    of course it was a bit of a generalization. However I don't think it's harder to use prepared statements and I do think you should always use it, even if you're absolutely sure that the data you get in isn't an injection. Not using it rings an alarm bell IMO.
  - __david__ 11y ago
    > If it's programmed correctly then it is exactly as secure as a prepared statement. That's a very big "if" right there. The same could be said for nearly every security flaw ever—if it were programmed correctly, it wouldn't be a security flaw. The reason people harp on prepared statements is not because you can't be secure without them, but that it's much easier to be secure with them. One you have to think about all the time (do I need to escape, do I not need to escape), while the other is almost completely secure against SQL injections by default. Same thing with using system() vs execve()[1]. One is a minefield of quoting issues, the other has none. [1] Or multi-arg system(), like in Perl or Ruby.
  - 11y ago
mrmondo 11y ago
Wow ok, that's even worse than I anticipated.

Ipfs exposes a JSON API locally. Not sure why the author didn't just use a JavaScript front end making calls to the local API. https://ipfs.io/docs/api/ https://ipfs.io/docs/api/ EDIT: I'd encourage the HN community to look past the technical merits of the code, and focus on the idea presented (and even perhaps fork and contribute back an improved version).

eis 11y ago
Hm what prevents some malicious website from pinning unwanted content on a visitors machine?
- Natanael_L 11y ago
  The visitor needs to chose to run IPFS and cache it
  - eis 11y ago
    He just needs to happen to have IPFS running. Any website can make a request to localhost via Javascript or even without. Scenario: Attacker sends you harmless looking link to a page that contains some invisible JS that sends a request to localhost and pins kiddypon on your IPFS node. Attacker then sends the police to you.
    - ossreality 11y ago
      um, cross origin blocking has been a thing for... like a really really long time now.
    - mappum 11y ago
      The IPFS API isn't exposed like that, there is actually a whitelist for hashes that can access the API (the IPFS webui is in the whitelist by default), and hashes that are blocked will get a 403.
mrmondo 11y ago
As you suggest, looking past the code quality / implementation choices I believe the idea if solid and it is a creative use of IPFS to attempt to 'solve' a real world problem, I'm excited to see more projects like this.

mweibel 11y ago

yep, and doesn't use prepared statements for DB queries..

PlzSnow 11y ago
There's nothing wrong nor insecure about choosing not to use prepared statements. There does seem to be a very conservative/cargo cult streak amongst some tech people that there are only pure ways to do things. For example there is nothing wrong with building a SQL statement as a string and passing it to a database. If it's programmed correctly then it is exactly as secure as a prepared statement.
- kevan 11y ago
  > If it's programmed correctly then it is exactly as secure as a prepared statement. It's really easy to program them incorrectly, and as a result the approach is less secure than just using prepared statements.
- mweibel 11y ago
  of course it was a bit of a generalization. However I don't think it's harder to use prepared statements and I do think you should always use it, even if you're absolutely sure that the data you get in isn't an injection. Not using it rings an alarm bell IMO.
- __david__ 11y ago
  > If it's programmed correctly then it is exactly as secure as a prepared statement. That's a very big "if" right there. The same could be said for nearly every security flaw ever—if it were programmed correctly, it wouldn't be a security flaw. The reason people harp on prepared statements is not because you can't be secure without them, but that it's much easier to be secure with them. One you have to think about all the time (do I need to escape, do I not need to escape), while the other is almost completely secure against SQL injections by default. Same thing with using system() vs execve()[1]. One is a minefield of quoting issues, the other has none. [1] Or multi-arg system(), like in Perl or Ruby.
- 11y ago

mrmondo 11y ago

Wow ok, that's even worse than I anticipated.