Skip to content

add connection timeout & fix banning for x-forwarded-for - #41

Open
LilithSilver wants to merge 4 commits into
mainfrom
config-connection-timeout
Open

LilithSilver wants to merge 4 commits into
mainfrom
config-connection-timeout

Conversation

@LilithSilver

Copy link
Copy Markdown
Collaborator

No description provided.

Comment thread docker/entrypoint.sh Resolved
Co-authored-by: Dan Nicholson <dbn@endlessaccess.org>
Comment thread src/web.rs
.on_upgrade(async move |socket: WebSocket| {
tracing::info!("Upgrade successful for {}", addr.ip());
state.server.accept_socket(SocketInfo(addr, socket)).await;
// TODO: this may be insecure -- we're blindly trusting an X-Forwarded-For header, which might be spoofed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically the way servers that are potentially behind proxies handle this is a "trust proxy" setting. Here are a couple I've seen:

Caddy - https://caddyserver.com/docs/caddyfile/options#trusted-proxies
Express - https://expressjs.com/en/5x/guide/behind-proxies/

So, I think a very reasonable thing would be a --trust-proxy boolean option that's false by default. You could take an IP/CIDR or something like Caddy does, but IMO a boolean is plenty good enough for anyone in this position.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dbnicholson Happy to do this! What would be your ideal behavior for the --trust-proxy flag? Trust all provided proxies, like the current code? Trust exactly 1 proxy?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I think simple boolean implying trust all is fine, IMO. There are definitely scenarios where someone could spoof it, but I don't think they're worth bothering with here. The most likely way this is going to setup is a trusted proxy on the same host with very little chance of being bypassed. A project like Caddy that's going to be used in all sorts of environments would want to provide more control. I don't think backstitch-sync-server needs that level of control.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is no longer accurate. I think you could remove it completely.

@dbnicholson dbnicholson left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks about right. I think the example compose files that use Caddy (docker-compose.caddy.yml and docker-compose.endless.yml) should have TRUST_PROXY: true since that demonstrates the exact use case --trust-proxy is being added for.

Comment thread docker/entrypoint.sh
--oidc-client-id "${OIDC_CLIENT_ID:-backstitch}"
--oidc-client-id "${OIDC_CLIENT_ID:-backstitch}" \
--connection-timeout "${CONNECTION_TIMEOUT:-10000}" \
--connection-timeout "${TRUST_PROXY:-false}"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you meant --trust-proxy here. However, I don't think clap boolean args work with a value. I think this needs to be:

if [ "${TRUST_PROXY:-false}" = "true" ]; then
    set -- "$@" --trust-proxy
fi

Comment thread src/web.rs
.on_upgrade(async move |socket: WebSocket| {
tracing::info!("Upgrade successful for {}", addr.ip());
state.server.accept_socket(SocketInfo(addr, socket)).await;
// TODO: this may be insecure -- we're blindly trusting an X-Forwarded-For header, which might be spoofed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is no longer accurate. I think you could remove it completely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants