Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http/cookiejar: escaped path matching #26247

Open
freman opened this Issue Jul 6, 2018 · 5 comments

Comments

Projects
None yet
6 participants
@freman
Copy link

freman commented Jul 6, 2018

Some servers and software return cookies with paths encoded

eg. /path/contains%20some%20spaces

Go's default cookiejar can't match those when we make calls back no matter how we make them

There are some characters in RFC6265 which should be encoded/escaped, but space isn't one of the ones listed. This might be a side effect of go being really nice with urls and making it so we rarely have to deal with escaped paths in code.

What version of Go are you using (go version)?

go version go1.10.3 darwin/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/user/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/shannon/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/08/9qf64r3d209cvmgznzj49zg40000gn/T/go-build088227774=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

https://play.golang.org/p/_3MyXdTJbm-

nb. The cookie set in that example is forced escaping to emulate what the software I'm calling is doing.

What did you expect to see?

all is well

What did you see instead?

cookie not found
cookie not found

How did you work around it

I copied cookiejar, modified jar.go to attempt to unescape the path, there might be a better option, but it worked for this instance.

@@ -369,6 +369,10 @@
 	if i == 0 {
 		return "/" // Path has the form "/abc".
 	}
+
+	if s, err := url.PathUnescape(path[:i]); err == nil {
+		return s
+	}
 	return path[:i] // Path is either of form "/abc/xyz" or "/abc/xyz/".
 }

@@ -386,6 +390,8 @@

 	if c.Path == "" || c.Path[0] != '/' {
 		e.Path = defPath
+	} else if path, err := url.PathUnescape(c.Path); err == nil {
+		e.Path = path
 	} else {
 		e.Path = c.Path
 	}
@meirf

This comment has been minimized.

Copy link
Contributor

meirf commented Jul 8, 2018

@freman

Some servers and software return cookies with paths encoded... There are some characters in RFC6265 which should be encoded/escaped, but space isn't one of the ones listed.

If encoding spaces isn't part of the spec, please specify which "servers and software" you are referring to. (The more popular the server/software, the more priority we should give to supporting.)

I copied cookiejar, modified jar.go to attempt to unescape the path, there might be a better option, but it worked for this instance.

I don't see anything wrong with your implementation. Probably worth sending a patch with the changes above (plus adding to jar_test.go).

@freman

This comment has been minimized.

Copy link
Author

freman commented Jul 8, 2018

@meirf

If encoding spaces isn't part of the spec, please specify which "servers and software" you are referring to. (The more popular the server/software, the more priority we should give to supporting.)

In this particular instance it's keycloak but I've had issues with a couple of other things before (including sadly the door security system in the office)

As usual, I'd be normally be on the side arguing to follow the letter RFC but it seems with Go's http client I can't construct a request with any amount of escaping that cookie jar would consider valid against the given cookie.

I don't see anything wrong with your implementation. Probably worth sending a patch with the changes above (plus modification to jar_test.go).

Sure, gladly. I was content just using a fork called "coooookie" for our own code but I'm finding anything we use from third parties now needs forking to use with our keycloak (as a client)

edit:

ooooh, jar_test.go's simple cookie test uses url.Parse(s) to both set it's cookies and test it's cookies, so it's automatically de-escaping

freman pushed a commit to freman/go that referenced this issue Jul 9, 2018

@freman freman referenced a pull request that will close this issue Jul 9, 2018

Open

net/http/cookiejar: unescape cookie paths #26284

freman added a commit to freman/go that referenced this issue Jul 9, 2018

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 9, 2018

Change https://golang.org/cl/122592 mentions this issue: net/http/cookiejar: unescape cookie paths

@ianlancetaylor ianlancetaylor changed the title net/http/cookiejar escaped path matching net/http/cookiejar: escaped path matching Jul 11, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 11, 2018

@vdobler

This comment has been minimized.

Copy link
Contributor

vdobler commented Dec 20, 2018

My reading of RFC 6265 is that encoding spaces in the cookie path is wrong.

RFC 6265 operates on the request-uri as defined in RFC 2616.
My reading of 2616 is, that the request-uri is the decoded
value: While a path may be written as /aaa%2fbbb during transport,
the actually request-uri is "/aaa/bbb".

This is what net/url.URL.Path represents and this value is used
as the request-uri's path part in the cookiejar.

The whole idea of a cookie path is to prevent the cookie to be sent
back somewhere it does not belong. If the Path attribute in a Set-Cookie
header is wrong (unacceptable for the path in the request), the cookie
is dropped. Like it is for domains. I really do not like the idea of relaxing
this security feature for a broken server.

Especially as this happens totally opaque between the http.Client and
the Jar.

I think the right solution for your use case would be to manage this
cookie manually: Extract it manually from the Set-Cookie header,
persist it and inject it back in subsequent requests manually.

@vdobler

This comment has been minimized.

Copy link
Contributor

vdobler commented Dec 20, 2018

The main question before changing cookiejar.Jar's behaviour would be to
investigate how browsers handle such Set-Cookie values. (And if they
only decode %20 or all %## sequences.)

If majority of actual browsers think it is safe to do this unescaping
then we could start thinking if adopting this too.

@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.