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...
@@identity is per session, but can return other things if you are using triggers (since the trigger will happen before your retrieval of @@identity). One more reason I hate triggers (we also use scope_identity only).
You're right. As mey pointed out via the docs, @@identity is for the current session, but may return unexpected results if a trigger fires as part of the statement(s) or if you are using replication. It's almost never what you actually wanted whereas scope_identity() is. Come to think of it, perhaps the vendor I mentioned was using ident_current('tablename') which returns the last identity generated for the specified table name regardless of session and scope; this would explain the resulting behavior of the app.
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.
Not so fast. You don't know if everything is coming down the pipe using SSL. They might be trying something fancy with AJAX, performing a remote call, the server spits back JSON on a regular connection, screws up the headers, and it gets cached. You really can't tell. It is a possibility.
I take it for granted that banks to stupid things. Just look at their password policies, for example. Many US banks basically prevent you from setting a strong password. Or my Austrian bank (http://www.easybank.at/) which includes Javascript code from typekit.com to use some Adobe fonts. Makes me feel much safer knowing that the security of my online banking interface does not only depend on my bank's site, but also on the security of Adobe's site.
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.
Fraud happens, the bank knows it, and if they have a system flaw they won't just blame the customer. The reputational risk isn't worth it.
Also, it isn't FDIC insurance at issue, read up on Reg E claims. Retail customers have a generous route by which they can dispute electronic charges to their bank accounts.
Definitely more informed than I am (upvoted). However, I would emphasize- the consumer remain concerned about their bank's security. You don't want to rely on the coverage and speed of dispute and remediations.
good question. BoA is designing their system internally since 1997 at least.
The newest version ate up $12MM and is very cool! One of the things I like is that when you create an internal ticket that something is broken, IT Dept has access to all your computer activity; no more screen shoots, error descriptions, etc, everything is recorded on the fly. They can rewind your PC activity 10 minutes (or whatever) prior and see exactly all the steps you took for the error to occur. Very time saving troubleshooting approach.
Edit: ok I meant they can rewind and play your interaction with the intranet systems per say, not the computer alone. But they are locked down pretty much anyways.
That sounds like a horrible to place to work in... I'd feel uncomfortable doing anything other then work, and any coder here can tell you that you need to do SOMETHING other then work every now and then or you burn out very quickly in the day.
I don't think that they are talking about recording what developer workstations are doing. They are talking about recording customer sessions in a replay-able format, so that they can see how the customer caused an error condition.
Well, its a some sort of an Internet Explorer plugin that records IE session, all the clicks, even mouse movement. Within BoA you can use Chrome browsers for your personal browsing, but as you can imagine, most of the websites are cut off. But Google works! :)
A lot of stubborn poorly run corporate giants cannot move on from IE 6 or 7 because of massive internal red-tape and costs! ( testing, upgrading windows and admin access to pc's for staff, so on ) To be fair Microsoft have ended support for IE7 and are aware its full of security holes. Microsoft recommend you keep up with the world of technology.
That doesn't seem likely. This person didn't reveal any personally identifiable information to the public. Have there been other (IMO, frivolous) lawsuits going after people who have identified holes in banking software?
In that particular case, the person was a security expert who spent time hacking (by way of URL) their system to expose information. And they threatened legal action but never went through with it (as they had no case).
In this particular case with Bank of America, a user did nothing out of the ordinary to expose information and reported it proper.
If I had 5 cents for every time I've read an article on someone going after the person reporting the hole in their software...I'd probably have at least enough to go get a soda from the company vending machine.
The sad state of affairs is that a lot of companies are more interested in security via cheap obscurity, and will gladly go after the person who dared to publicize their security holes.
The difference here, is that unlike URL-hacking, or some-such, they would have a hard time arguing that a user using their product exactly as intended was doing something against the law.
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".
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.