1

I am logged in to my banking site and I see this kind of form POST data in the Developer tools of Chrome:

accountNo: removed for security reason
branchCode: removed for security reason
fromDate: U2FsdGVkX1+73zpLsKOLUO+go3Ft2z9qV+rvOGEfcnk=
toDate: U2FsdGVkX1/Ur2O/lk5d5J5uiHVFjeIfC/hBBucUodg=
order: 1
noOfRows: ALL
pageNumber: 1
fileFormat: 
request_Id: 
radiobuttonPeriod: 6Month
accountType: A1
gkkj: iit9133r7apgb1ieh69bfs82a5d9166d

I wanted to understand how is the data obfuscated. Example the accountNo and branchCode were in plain text but the fromDate and toDate are obfuscated. Additionally there is a cryptic string like gkkj which might be some token code. But this token name and code keeps on changing. For example, on one of the other pages I see this as token:

t34j: hpo9mcs4rp2jrmohber34ifm8q22rn8a

Why would somebody obfuscate this POST data? Already the site uses TLS.

Why would one want to do this?

schroeder
  • 129,372
  • 55
  • 299
  • 340
K V Sharma
  • 11
  • 1
  • The dates are base64 encoded with an AES encrypted payload. There are easily findable libraries in C# to do either of those things. You will have to work with your bank on what t34j would mean or what it is for. – schroeder Apr 28 '23 at 10:39
  • Indeed, being that the connection between the web browser and web server is secured via SSL/TLS, there is no need for any further encryption or obfuscation to prevent a man in the middle from intercepting or modifying these requests. The reason that this site may be employing this obfuscation could be to make it more difficult for automated programs/scrapers/bots to make automated requests to the site. – mti2935 Apr 28 '23 at 12:14
  • Interestingly, if you base64-decode the date string (e.g. echo -n 'U2FsdGVkX1/Ur2O/lk5d5J5uiHVFjeIfC/hBBucUodg=' | base64 -d | xxd) and examine the underlying bytes, the first eight bytes are the ascii characters for Salted__, which is the same format that openssl enc uses to store the salt with the ciphertext, when deriving a key from a password for AES encryption. See https://security.stackexchange.com/questions/20628/where-is-the-salt-on-the-openssl-aes-encryption for more info. – mti2935 Apr 28 '23 at 12:22
  • Encryption makes no sense in this case. What can be the reasons for what you see? 1) As "mti2935" says, this might be an attempt to prevent request automation. If this is the reason, then it is very naïve, because since 10 - 15 years there are exist many tools for GUI / browser test automation (from old Selenium to newer Cypress or Playwright). Encryption ( obfuscation will not prevent automation. – mentallurg Apr 28 '23 at 20:22
  • Another reason might be an attempt to prevent modification of some data, for instance, if some fields are read-only or if some data were validated on previous steps and developers want to skip validation. Again, such approach is very naïve. If these data are displayed in browser, it means, there is code to decrypt them. "schroeder" says, it is AES. Then it is possible to extract the key and to encrypt something other.
    • – mentallurg Apr 28 '23 at 20:27
  • In case data were encrypted on the server side and developers want to prevent users from encrypting some other data, they may use MAC for authentication. This would prevent modification of specific value, but user can copy such encrypted values from other cases, if some user has several accounts, it is easy to copy encrypted value when using one account and apply it when using another account. Thus the user will be able to change the data even without knowing anything about encryption used.
    • – mentallurg Apr 28 '23 at 20:33