I ran into something similar while working with a Seattle-based email vendor years ago. They had an online survey application which recognized your user information by a special token, created a new entry in a table for your survey, then proceeded to display your information. In launching a high-volume campaign, people started complaining that they were seeing other people's contact information.
They never admitted it, but I'm 100% sure that the issue was that (in SQL Server) they were doing:
select @@identity
Rather than the correct call of:
select scope_identity()
The former retrieves the identity of the latest record entered into the table regardless of what SQL statement produced the record (such as another user connecting to the database from a different connection thread); the latter retrieves the identity of the record entered from the current session.
Are you sure about that? I am almost positive that you're wrong, and @@identity is per connection. Otherwise how woul it know which table to return an identity for?
I thought that the difference had to do with what's returned if a trigger does an insert or something like that...
I had something similar happen with Wells Fargo. Logged in and saw someone else's name, Florida purchases (I'm in Montana), along with a different account number, statement history, etc.
Naturally, I recorded this with Quicktime and then called WF. Their response: "It's not a big deal -- neither accounts can withdraw money." After repeatedly explaining how serious this is for identity theft, I was told to wait 10 days. Their solution was to shutdown my online account without notice. If no one can login, then it's safe!
It took over a month to get this resolved, and once I could download my statements, I "cancelled" my account. WF is like Hotel California though -- a year and many phone calls later, my accounts still aren't closed.
This is mostly unrelated, but some might find it interesting. I went to a Wells Fargo ATM to make a transaction, but the machine was in a sort of debug mode. The bank was closed. I messed around with it for a minute or two because I was curious. Then I remembered the cameras and decided I ought to get the hell out of there.
There was a story like this in the ny times a while ago. Some guy could access another account. Turns out they were both named John smith or something, and had respectively picked johns and jsmith as usernames. And used the same password, wife's name or something. Guy uses wrong username, guy logs into wrong account.
> It’s clear that had I gone through with this payment it would have come out of WATSON’s account and not mine.
No it's not clear. You're just looking at some HTML on the screen, it may have come out of some stale cache and have nothing to do with the session's current permissions. You might try to do the transfer and find that the internal state of your session is so hosed that you can't do anything.
A little OT but I just realized a compromised facebook could do more harm than a compromised bank account. With a compromised bank account, at least you are guaranteed your money back. Who's gonna return broken relationships and undo other harm caused by facebook privacy screw ups like this? Facebook better begin taking privacy as serious as banks take security. It will naturally SERIOUSLY slow down the pace at which they can do new releases but at this point, they've given pretty granular privacy control that hundreds of millions of people use with the expectation that it will work.
Why do you think you have a guarantee of your money back? In the US FDIC insurance insures against the bank going under. If the bank refuses to believe there was fraud I bet you have very little recourse (i.e. they have a huge interest in claiming you transferred the money). In the US you can dispute credit card charges- but that is due to a separate act of congress.
This could be a session crossover issue. Here's IBM's documentation on it:
"In rare situations, usually due to application errors, session data intended for one client might be seen by another client. This situation is referred to as session data crossover. When the DebugSessionCrossover custom property is set to true, code is enabled to detect and log instances of session data crossover. Checks are performed to verify that only the session associated with the request is accessed or referenced. Messages are logged if any discrepancies are detected. These messages provide a starting point for debugging this problem. This additional checking is only performed when running on the WebSphere-managed dispatch thread, not on any user-created threads."
I had this happen to me on Google. I opened up Google Reader, and poof, I was staring at someone else's set of feeds, but I could also navigate to gmail.com and access their email. I wasn't able to reproduce it after logging out. https://twitter.com/anantn/status/81128281197387776
The most convincing explanation I received was that it was a cookie collision. Very small chance, but still possible...
Looks like BofA rolled out a new web site based on the UI changes from last month when I last used it. In addition to the new Random Accounts feature, it broke the ability to make mortgage payments "Error in mort-review-pmt-module-hemi-mpw-skin".
[+] [-] biot|13 years ago|reply
They never admitted it, but I'm 100% sure that the issue was that (in SQL Server) they were doing:
Rather than the correct call of: The former retrieves the identity of the latest record entered into the table regardless of what SQL statement produced the record (such as another user connecting to the database from a different connection thread); the latter retrieves the identity of the record entered from the current session.[+] [-] Johngibb|13 years ago|reply
I thought that the difference had to do with what's returned if a trigger does an insert or something like that...
[+] [-] jmdeldin|13 years ago|reply
Naturally, I recorded this with Quicktime and then called WF. Their response: "It's not a big deal -- neither accounts can withdraw money." After repeatedly explaining how serious this is for identity theft, I was told to wait 10 days. Their solution was to shutdown my online account without notice. If no one can login, then it's safe!
It took over a month to get this resolved, and once I could download my statements, I "cancelled" my account. WF is like Hotel California though -- a year and many phone calls later, my accounts still aren't closed.
[+] [-] macchina|13 years ago|reply
Pics related: http://i.imgur.com/T77ni.jpg http://i.imgur.com/WdiZK.jpg
[+] [-] tedunangst|13 years ago|reply
[+] [-] dmethvin|13 years ago|reply
No it's not clear. You're just looking at some HTML on the screen, it may have come out of some stale cache and have nothing to do with the session's current permissions. You might try to do the transfer and find that the internal state of your session is so hosed that you can't do anything.
[+] [-] pacomerh|13 years ago|reply
[+] [-] pav3l|13 years ago|reply
[+] [-] Zarreon|13 years ago|reply
United, in spite of all their other faults, handled it fairly well at least and responded quickly.
[+] [-] zaidf|13 years ago|reply
[+] [-] jmount|13 years ago|reply
[+] [-] ClayM|13 years ago|reply
WELP
[+] [-] sgornick|13 years ago|reply
[+] [-] savramescu|13 years ago|reply
[+] [-] nicksergeant|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] schizoidboy|13 years ago|reply
"In rare situations, usually due to application errors, session data intended for one client might be seen by another client. This situation is referred to as session data crossover. When the DebugSessionCrossover custom property is set to true, code is enabled to detect and log instances of session data crossover. Checks are performed to verify that only the session associated with the request is accessed or referenced. Messages are logged if any discrepancies are detected. These messages provide a starting point for debugging this problem. This additional checking is only performed when running on the WebSphere-managed dispatch thread, not on any user-created threads."
http://www14.software.ibm.com/webapp/wsbroker/redirect?versi...
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] anant|13 years ago|reply
The most convincing explanation I received was that it was a cookie collision. Very small chance, but still possible...
[+] [-] tawman|13 years ago|reply
[+] [-] nathantone|13 years ago|reply
[+] [-] ToesByNoon|13 years ago|reply
[deleted]