Our most popular bank sends secret codes via GET parameter 😞

C'mon Yuri, it's encrypted, it will be fiiiiine 😋

@rutee07 smells like someone was paid to make it easier to sidejack.

@SortOfTested @uyouthe

At least they could encrypt it with Base64 ... And why not GET?

(So many intended pun(che)s)

Not encrypted tho. Not even in base64. Nothing. Just the raw code

Now don't get me wrong, best practices here and there but what exactly is the difference to a post request here when it comes to security? Both are perfectly readable.

@nitwhiz
Even when ssl encrypted, get request paths appear in history. Extensions can read pages, addresses and history if granted permissions.

@SortOfTested not thought of that, absolutely true.

@SortOfTested You know, when you post shtuff, I realize I have no clue about certain programming topics. Web security is definitely one I don't know a lot about.

The ""fun"" thing is that a lot of the stuff regarding HTTP security / behavior is based on the RFC.

Eg. POST requests are not idempotent, which is the reason why it cannot be cached from an RFC perspective.

Two identical calls - different results.

Read the HTTP RFC.

And I mean it in a positive way. Most (not all) browsers comply to sane behavior, like a Gentleman's agreement.

Which is a good thing.

Look at EMail. Now that's an abomination where there was an RFC .... And then everybody did implement it in different ways.

That's a bad thing. ;)

devRant sends login via GET.
So yeah

@IntrusionCM Base64 is not encryption because there are no secrets required to reverse it. It's functionally equivalent to cleartext.

@Root it was meant as a joke

@Root

Encoding with key -> Encryption
Encoding without key -> yeah just encoding lol

@IntrusionCM Wanted to make sure 😋

@Root ;)

Although I think that there are definitely companies out there who use Rot 13... Or vignere chiffre.

@kescherRant hm. no. :)

When you use the same key over and over the encryption is useless.

@nitwhiz urls wind up in a lot of places (logs and browser history for example). So in general put data that are not really parameters to what you are GETting in POST data. If it's a OTP the problem in is mostly mitigated (if you need real time in flight access you can probably also read post data).

@hjk101 i never thought as far as the browser history. I always thought well yeah it's in the logs but if you can read those, everything is lost anyways.:D

Nah, imo everything that isn't intended to be "shared" (as in here, click that link, and the other person sees the exact same thing as me) shouldn't be in the query params. An OTP e.g. is not a query paramter, it doesn't decide the output (well, aside from 200 or 403), it's data. Data goes via POST.

@nitwhiz depends on what the GET endpoint does. GETs should never change content on the backend, if it doesn't, then its not *as* risky... But if the code is protecting some action its problematic.

For example GET requests are used for image loading, which means an attacker can include the banks endpoint into an <img> tag, that makes it much easier to exploit even via email compared to a POST... However if the bank uses other XSS protections it might not be a problem... GET is also excluded from some content security policy protections I believe, so a user can become a victim easier if the endpoint is something important...

Its just all around better to use POST for anything actually important...

If the banks endpoint only retrieves some data and nothing else than as long as its behind https its pretty safe

@nitwhiz Also, get params usually appear in web server log files. And if you log every requests and keep the data for quite a while...