ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.16k stars 3.01k forks source link

gateway: feature request: ability to disable directory listings #9645

Open delgyd opened 1 year ago

delgyd commented 1 year ago

tldr; I would like one more option to support blocking listing directory contents

Checklist

Description

https://ipfs.io/ipfs/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9 【let him redirect】 https://ipfs.io/ipfs/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9/VCG211be3c9c31.jpg 【OK】 https://ipfs.io/ipfs/QmcBpxUZMbD5iwNA8w2dj8QBWvTdAXwNDHbZ74ffqGtNHh  【OK】

Because certain scenarios have relatively strict security requirements, directory traversal caused by direct get access is considered a security issue. Therefore, it is recommended to directly redirect to the specified page when accessing indirect data resources, instead of directly using the form of directory traversal, or Add a parameter directly in the configuration file to achieve.

lidel commented 1 year ago

Mind elaborating what is the exact problem you see, how threat model looks like, and what is your proposed solution?

My understanding is that you don't like the fact someone can list directory contents, which is not a bug. All data stored on IPFS is in the clear, directory structures can be trivially inspected, all you need it CID:
https://explore.ipld.io/#/explore/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9

If you remove CIDs, then you lose the ability to do content-addressing, and end up with regular HTTP without being able to do integrity checks (which is fine, but that also suggests you don't need what IPFS provides).

delgyd commented 1 year ago

Yes. This is not a bug, but I would like one more option to support blocking listing directory contents

kubo/core/corehttp/gateway_handler.go

if strings.HasSuffix(resolvedPath.String(),"/") == true { http.Redirect(w,r,"https://ipfs.io",302) return } else { trace.SpanFromContext(r.Context()).SetAttributes(attribute.String("ResolvedPath", resolvedPath.String())) }

Jorropo commented 1 year ago

@delgyd the directory content is stored publicly inside the block, if you block it on your gateway that does not prevent someone from just using an other gateway or running their own IPFS node.

If https://example.org/ipfs/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9 blocks directory listing, what does this achieve if I can just use https://jorropo.net/ipfs/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9 ?

delgyd commented 1 year ago

For gateway access, you only need to achieve the following effects

http://89.163.225.14:8980/ipfs/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9/VCG211be3c9c31.jpg

http://89.163.225.14:8980/ipfs/Qmd148AbtEZKR4KCUZiNGDURTxCwSa13adLKkjdmyWPMt9

lidel commented 1 year ago

I would like one more option to support blocking listing directory contents

Ack. It is not related to security in any way, so low priority for the team.

But it makes UX sense in context of DNSLink websites, where one may want to keep all HTML returned under own brand, and generated dir listings break that consistency.

If someone wants to work on this, next steps:

arthurgavazza commented 1 year ago

Anyone working on this? I'm looking for a good first issue and would appreciate taking this one. I just need some help to understand the tasks.