Skip to content
This repository has been archived by the owner on Jan 6, 2020. It is now read-only.

Malformed URLs not filtered by launcher #159

Open
davidpbrown opened this issue Jun 20, 2016 · 0 comments
Open

Malformed URLs not filtered by launcher #159

davidpbrown opened this issue Jun 20, 2016 · 0 comments

Comments

@davidpbrown
Copy link

davidpbrown commented Jun 20, 2016

I can't see the problem directly but wonder that the launcher/proxy is not checking URLs put to it and instead relying on the network's response.

Also, I notice that certain characters appear to see the launcher hang and they get no quick reply.. or likely none at all.

The usual reply to a non-existent domain appears to be of the form:

ERROR 21:36:51.503097038 [safe_core::ffi mod.rs:330] 

 --------------------------------------------------
| FfiError::DnsError -> DnsError::CoreError -> No such dataCoreError::GetFailure::{ reason: NoSuchData, request: Structured(dc641a.., 5)}
 --------------------------------------------------

I would have expected a different type of error for malformed urls, like abc_def.safenet or uvw#xyz.safenet

So, a PublicID.safenet and I would expect also Subdomain.PublicID.safenet containing # ! * appear to hang waiting forever, while other characters like _ and - get a quick not found error.

Could launcher proxy filter invalid publicID and subdomain names in safenet URLs? To be clear, it seems the error response is identical to nonexistent domain reply and perhaps that's an unneeded request for the network to deal with. Obviously, the network would still need capability to reject those bad requests but surely it's better not see normal sending of those.

Note: I'm seeing this when using wget to request files and the response in the launcher's terminal. I can't tell a difference between the hanging requests that follow from characters like # ! * in .safenet requests and that which occurs for bad urls outside of .safenet - so .safetynet hangs in the same way and perhaps those characters cause a confusion in wget rather than in the launcher. Still, I worry that the characters not being handled might risk user input interactions in the launcher, if that input is being trusted or put to the network without filtering for only [a-z0-9].

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant