This question already has an answer here:
I'm testing a webapp as part of a bug bounty program where the value of a product ticket given to clients is being encoded.
FYI, ticket number is given to an user for an adquired product. Webapp has an input field where ticket number can be entered for information on product's status. The ticket number entered is sent to server and encripted, page reloads while emptying said input field, requests ticket number to server, decodes it an puts it back on input field for results page.
For an arbitrary ticket number: 1111111111111, the encripted string looks like this:
Or this (when decoding the URL characters in it):
I've dissected this encoded string as follows:
2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU%3D OR 2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=
This appears to be some salt or something like that, as it will appear pre-fixed in other encoded values such as client number.
vK1%2BrOrlrThJWBCPGY5f2vzfJOFMCGd%2FS5%2BaM%2FX%2F6No%3D OR vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=
This is what I would call the "dinamic" part of the encoding, as this varies with ticket number.
Upon testing, I've come to observe the following:
It doesn't matter if '%2f' or '%3D' are written as '/' and '=' respectively, as server will decode the string and return the given ticket number in both cases. On the counterpart it does matter if '%2B' is passed as '+' as server will return ticket number's input field empty.
The ending '%3D' are necessary for decoding, striping the string from it's ending %3D character will result in an empty input field.
I've triend with onlin decoders with no luck.
Sorry if I extended myself too much, but I wanted to give you as many info as possible as I am not familiar with encoding methods. I hope someone can give a hand with this. Thanks in advance.