Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
dfox428287y@Kimmax very well put. It’s been a bit frustrating :)
I honestly think it might come down to some people not being aware the URL string is in fact encrypted the same way POST data or any other secure request data it.
There was a guy who called out on Twitter and claimed the login was insecure because we “were sending his password in plain text because he could see it in his network requests panel.” An awesome security researcher/expert actually called him out on it as did others and after a long exchange he realized he was wrong (after cursing us out) and deleted his ridiculous tweet.
Related Rants
-
Skipp36What devrant taught me: Everyone hates java Everyone hates php Everyone hates spaces Everyone hates tabs Ever...
-
yashmehrotra28*Me and my GF who works for CIA* Me: Send nudes GF: Whose do you want ?
-
tommy15Right now someone at Google is coding something useless for us to laugh at on April Fools.
So I have seen this quite a few times now and posted the text below already, but I'd like to shed some light on this:
If you hit up your dev tools and check the network tab, you might see some repeated API calls. Those calls include a GET parameter named "token". The request looks something like this: "https://domain.tld/api/somecall/..."
You can think of this token as a temporary password, or a key that holds information about your user and other information in the backend. If one would steal a token that belongs to another user, you would have control over his account. Now many complained that this key is visible in the URL and not "encrypted". I'll try to explain why this is, well "wrong" or doesn't impose a bigger security risk than normal:
There is no such thing as an "unencrypted query", well besides really transmitting encrypted data. This fields are being protected by the transport layer (HTTPS) or not (HTTP) and while it might not be common to transmit these fields in a GET query parameter, it's standard to send those tokens as cookies, which are as exposed as query parameters. Hit up some random site. The chance that you'll see a PHP session id being transmitted as a cookie is high. Cookies are as exposed as any HTTP GET or POST Form data and can be viewed as easily. Look for a "details" or "http header" section in your dev tools.
Stolen tokens can be used to "log in" into the website, although it might be made harder by only allowing one IP per token or similar. However the use of such a that token is absolut standard and nothing special devRant does. Every site that offers you a "keep me logged in" or "remember me" option uses something like this, one way or the other. Because a token could have been stolen you sometimes need to additionally enter your current password when doings something security risky, like changing your password. In that case your password is being used as a second factor. The idea is, that an attacker could have stolen your token, but still doesn't know your password. It's not enough to grab a token, you need that second (or maybe thrid) factor. As an example - that's how githubs "sudo" mode works. You have got your token, that grants you more permissions than a non-logged in user has, but to do the critical stuff you need an additional token that's only valid for that session, because asking for your password before every action would be inconvenient when setting up a repo
I hope this helps understanding a bit more of this topic :)
Keep safe and keep asking questions if you fell that your data is in danger
Reeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
rant
devrant
security