One of our big apps at work is pretty flaky. It has a tendence to crash on startup, so a recent circular came round from IT telling people to delete the files in "C:\CACHE" because sometimes they cause it to crash on startup.
Rather curious, next time the app crashed, I went to take a look at what the cache files did.
They appeared to be a bunch of text files that held copies of the main app data tables, presumably so that the client software could do join on those tables, rather than troubling the database server for every UI element.
Even more surprising was the content of the multi-MB 'users.txt' file. This appeared to contain a complete copy of the users table on the app-server. It would read like:
[UserName=DOEJOHN1]
Fullname=John Doe
JobTitle=System administator
IsAdministator=1
AccountDisabled=0
Password=XAB16OUP
OldPassword1=HY7023HDD
OldPassword2=BJK5CGKL7
with an entry for every single user.
It didn't take long to find my login, and thankfully the passwords were encrypted. Using a 'known plaintext attack' (my recollection of my last 5 passwords) it was pretty obvious that the 'encryption' was a Vigenere cipher modified to include numbers as well as letters.
I just haven't come across such a peculiar design before - I can understand caching some tables - but surely these type of joins are better done by a DBMS (oracle in this case) than some custom code in the client app.
However, I was somewhat surprised at the size of the security hole that this design leaves in the app. The data in the underlying database is highly privileged and strictly confidential, and strict access control are mandated under law. Even more astonishingly, was that this app was the flagship product from a specialist IT vendor. This particular vendor has had some had press about poor quality software - but even I wasn't expecting such poor security design.
Rather curious, next time the app crashed, I went to take a look at what the cache files did.
They appeared to be a bunch of text files that held copies of the main app data tables, presumably so that the client software could do join on those tables, rather than troubling the database server for every UI element.
Even more surprising was the content of the multi-MB 'users.txt' file. This appeared to contain a complete copy of the users table on the app-server. It would read like:
[UserName=DOEJOHN1]
Fullname=John Doe
JobTitle=System administator
IsAdministator=1
AccountDisabled=0
Password=XAB16OUP
OldPassword1=HY7023HDD
OldPassword2=BJK5CGKL7
with an entry for every single user.
It didn't take long to find my login, and thankfully the passwords were encrypted. Using a 'known plaintext attack' (my recollection of my last 5 passwords) it was pretty obvious that the 'encryption' was a Vigenere cipher modified to include numbers as well as letters.
I just haven't come across such a peculiar design before - I can understand caching some tables - but surely these type of joins are better done by a DBMS (oracle in this case) than some custom code in the client app.
However, I was somewhat surprised at the size of the security hole that this design leaves in the app. The data in the underlying database is highly privileged and strictly confidential, and strict access control are mandated under law. Even more astonishingly, was that this app was the flagship product from a specialist IT vendor. This particular vendor has had some had press about poor quality software - but even I wasn't expecting such poor security design.
Facebook
Twitter