LDAP Auth requests are passed insecurely with credentials in URL
Closed this issue · 19 comments
Enabling "DEBUG" output on the Traefik gateway logs, these entries may be found:
time="2019-07-02T01:43:51Z" level=debug msg="vulcand/oxy/roundrobin/rr: completed ServeHttp on request" Request="{\"Method\":\"POST\",\"URL\":
{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/sso/oauth/token\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"grant_type=password\\u0026password=asdfdfsa\\u0026username=ddssdf\",\"Fragment\":\"\"}
Shouldn't credentials be passed as form data so they aren't as in the clear?
Would a maintainer please care to comment on this design decision?
@englandprevails which version of service-apiyou use?
@DzmitryHumianiuk I'm having the same issue, service-api - 4.3.4, I believe that's the latest.
@DzmitryHumianiuk I'm also using service-api:4.3.4
@englandprevails @Avielyo10
try
service-api 4.3.11
service-ui 4.3.7
The new images made no difference:
$ oc describe deploy api |grep Image
Image: reportportal/service-api:4.3.11
$ oc describe deploy ui |grep Image
Image: reportportal/service-ui:4.3.7
I added "--logLevel=DEBUG" to the gateway, and following its logs shows this:
time="2019-09-16T19:35:28Z" level=debug msg="vulcand/oxy/roundrobin/rr: completed ServeHttp on request" Request="{"Method":"POST","URL":{"Scheme":"","Opaque":"","User":null,"Host":"","Path":"/sso/oauth/token","RawPath":"","ForceQuery":false,"RawQuery":"grant_type=password\u0026password=SECRETP%40%24%24W0RD\u0026username=foo","Fragment":""},"Proto":"HTTP/1.1","ProtoMajor":1,"ProtoMinor":1,"Header":{"Accept":["application/json, text/javascript, /; q=0.01"],"Accept-Encoding":["gzip, deflate, br"],"Accept-Language":["en-US,en;q=0.5"],"Authorization":["Basic dWk6dWltYW4="],"Content-Length":["0"],"Content-Type":["application/json;charset=UTF-8"],"Cookie":["s_fid=35593E3DFA673AB1-26B2D01B839B0845; s_vi=[CS]v1|2E434AE70507B792-40000113E002599E[CE]; AMCV_945D02BE532957400A490D4C%40AdobeOrg=-1712354808%7CMCAID%7C2E434AE70507B792-40000113E002599E%7CMCIDTS%7C18153%7CMCMID%7C29459060138664963847475843834951171452%7CMCOPTOUT-1568396088s%7CNONE%7CvVersion%7C4.3.0; kc_authenticated=3B10C81522943D78D1E71DA5B9E6017842AF9AB6F0AE93D1BA7AC20024B43A01; AMCVS_945D02BE532957400A490D4C%40AdobeOrg=1"],"Dnt":["1"],"Forwarded":["for=XXX.XXX.XXX.XXX;host=reportportal-test.local.site;proto=https;proto-version="],"Referer":["https://reportportal-test.local.site/ui/"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"],"X-Forwarded-For":["XXX.XXX.XXX.XXX"],"X-Forwarded-Host":["reportportal-test.local.site"],"X-Forwarded-Port":["443"],"X-Forwarded-Prefix":["/uat"],"X-Forwarded-Proto":["https"],"X-Requested-With":["XMLHttpRequest"],"X-Xsrf-Token":["undefined"]},"ContentLength":0,"TransferEncoding":null,"Host":"reportportal-test.local.site","Form":null,"PostForm":null,"MultipartForm":null,"Trailer":null,"RemoteAddr":"172.54.6.1:33602","RequestURI":"/sso/oauth/token?grant_type=password\u0026password=SECRETP%40%24%24W0RD\u0026username=foo","TLS":null}"
@avarabyeu could you please comment here?
@DzmitryHumianiuk
Again the same here
@englandprevails @Avielyo10 folks, did you try v5 compose?
https://github.com/reportportal/reportportal/blob/master/docker-compose-v5.yml
We made some relevant fixes in it.
looks like it's already fixed issue, but should be double checked.
@DzmitryHumianiuk , I tried to run v5 [from source] and I couldn't even login :/
Downloading from the beta release seems to be working well
@Avielyo10 no login - no LDAP issues 😅
Kidding
See why microservices are not running.
Check the docker logs.
@DzmitryHumianiuk
From elastic search - Caused by: java.nio.file.AccessDeniedException: /usr/share/elasticsearch/data/nodes
From postgres - FATAL: role "postgres" does not exist
Downgrading elastic search image to 7.2.0 - let me login but those errors still appear.
UPDATE - The supported version of elasticsearch is now 7.3.2, this version works for me.
@Avielyo10 plz check credentials in logs
@DzmitryHumianiuk
The issue has found on 4.3.7.
On urls.js this should be like on v5 urls.js
Also this method should be fixed accordingly to look like this method on v5
It appears that this security flaw may have been resolved in July:
reportportal/service-ui#1814
I cannot use V5 simply because it's in beta, so we must wait for that fixed version of V4 to be released.
@DzmitryHumianiuk can you give an estimate of when we might see this V4 release?
@englandprevails i will announce release candidate today for v5.
we will release v4 fixes after all things done with v5.
can't predict any exact dates for v4
Fixed in 5.0
Was this change backported to v4 / is there any plan to backport it?