1683477 - sensitive information leakage in URL (email & password)

Status: RESOLVED INCOMPLETE

(Pocket :: getpocket.com, task)

Description

[Harry Benyamin]

hi, i found a vulnerability that exposes very sensitive informations on the URL
when you login, your informations (email and passwd) get leaked in the URL which is bad
when i tried to create an account and clicked on the sign up button it sent me to the next step of registration and as the below links show that i was able to see the name , email and the password
( https://getpocket.com/signup?name=Harry+Benyamin&email=harrydz2003%40gmail.com&password=H%40rry0550&homephone=&form_check=543ee2da4a92a6b484e8b05686b0dcee4137567b6ba4da968eeac39e4418353b&from_source=&request_token=&source=&route=&src= )
( https://getpocket.com/signup?name=harry+dzdzdzdz&email=harrydz2003qsdza%40gmail.com&password=H%40rry0550%26%C3%A9%22%27&homephone=&form_check=8305bf4657995fef9de381cf8cf5942a7339efd6d72a201f7b5048d082195f7a&from_source=&request_token=&source=&route=&src= )

and by using burp suite as the video show you can see the user informations

Comment 1

[Harry Benyamin]

Attachment: bandicam 2020-12-19 13-19-25-086.avi

Comment 2

[Harry Benyamin]

Attachment: Screenshot_1.png

Comment 3

[Harry Benyamin]

Attachment: Screenshot_2.png

Comment 4

[Harry Benyamin]

Attachment: bandicam 2020-12-19 13-19-25-086.avi

Comment 5

[Harry Benyamin]

NOTE : Attackers may turn the following url ( https://getpocket.com/signup?name=&email=&password=&homephone=&form_check=&from_source=&request_token=&source= ) to CRLF attack

Comment 6

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Pocket Engineering bug: https://getpocket.atlassian.net/browse/SEC-114

Comment 7

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Harry: Could you provide more insight into how a user would end up following such a flow using the application? The feedback I'm getting from our engineering team is that we use POST (not GETs), the signup page is not what processes logins, there's a reference to "homephone" that not used at all by our system. From those signals, I'm guessing your Burp proxy is inserting those and they are not used by normal user flows on the application, please advise.

Comment 8

[Harry Benyamin]

Hi thanks for your reply ,
and I can't read the Pocket Engineering bug ,when i try to create an account to see the report it say : [e-mail] doesn't have access to Jira on getpocket.atlassian.net.

and the vulnerability is in the URL , because sometimes you will see your informations (PWD , Email , Name) in the URL when you create an account

Comment 9

[Harry Benyamin]

https://getpocket.com/signup?name=Harry+Benyamin&email=harrydz2003%40gmail.com&password=H%40rry0550&homephone=&form_check=543ee2da4a92a6b484e8b05686b0dcee4137567b6ba4da968eeac39e4418353b&from_source=&request_token=&source=&route=&src=

Like what we see here : the name is ( Harry Benyamin ) , email is ( [e-mail] ) and the password is ( H@rry0550 )

Comment 10

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Harry: My point here in asking more probing questions about how that URL was generated is more to ascertain whether this URL is generated via set of normal user flows or if this is simply your scanner crafting such a URL. To be more blunt, we could simply add "credit_card=41111111" to the parameter path in the URI as part of a fuzzing activity, but having a URL such as this in your site tree does not necessarily mean this is a weakness in the product. I think what could help this report would be to document the series of requests a user would follow that could land them in a position of posting a URI such as this.

Example:

1.) Go to getpocket.com
2.) Click link xyz
3.) submit form abc
4.) submit action reveals a URI of lmop

Let me know if that helps more clearly articulate what I'm asking for here.

Additionally, the Pocket engineering bug is private, which is why you don't have access to it. We're working on trying to make this process with Pocket bugs more transparent, but it is a work in progress.

Comment 12

[Daniel Veditz [:dveditz]]

Oops, wrong bug
This is probably a duplicate of bug 1683477. The two names resolve to different addresses, but they surely are built from the same code. But I'll leave this as a "depends on" until we see where the fix actually is.