Hacker News Reader

Comment by tptacek | Hacker News Reader

You don't find a lot of SQLI and XSS in global retail banking applications (well, you do, but only in the pentest on the staging environment). A padding oracle that lets you corrupt clientside state, though: pretty devastating.

View on HN

We clearly don't deal with the same banks. I'd say XSS is the number one most commonly found vuln we come across in financial sector web apps. Some of our customers even accept the risks associated with it because the cost of fixing it is greater than the resulting insurance-adjusted loss.

SQL Injection happens now and again but less often, possibly because with a lot of the banks we deal with they're not necessarily using an SQL backend as opposed to some sort of broker for backend systems. If you can abuse the broker though (and that is a common theme) then there's all kinds of fun/problems to be had.

We're in NYC and Chicago and financial services is a practice focus, but this is a distinctively unproductive argument to have. Clearly there are banking applications that have XSS. Clearly some of those XSS flaws make it into product. Sometimes, this even happens in retail banking apps; it may have happened on the retail banking apps of a global bank somewhere.

I think if you re-read my comments in the context I wrote them in, you'll see that all I'm saying is that there are heavily-audited apps for which a padding oracle flaw would be a reasonable first step for an attacker.

To concur with Thomas' statement above, I've been doing application testing for about 11 years now (predominantly in the Financial sector), and with the exception of when XSS was initially discovered (and over-hyped) I don't regularly encounter production e-commerce or online banking apps which are vulnerable to XSS.

When XSS was discovered, we had one large financial institution that we did testing for make us go back and retest all the applications we'd tested for them for XSS (this was about 20 online banking apps), and for about the next two years, it would pop up in tests for other clients.

I can safely state that now it's pretty rare though, as the majority of the applications we're looking at have been tested annually, and the low hanging fruit has been picked a long time ago.

But this type of attack, like most crypto attacks, seems to be singular in nature. It's one thing to have access to the client-side state via (machine compromise or MITM) of a single person or single computer. But it certainly seems that attacks of this directed nature are not very common against web apps. It seems more likely that a huge net is thrown against a large number of computers and a few get compromised. Hardly a directed attack.

It seems that weaknesses like these, while problematic and fun to discuss, are not really the ways in which web applications are generally attacked.

That's not even a little bit true. Are there people dragnetting the Internet looking for the same Wordpress flaw over and over again? Yes. Does that mean people aren't spending hours/days/months attacking single banking apps? Of course they are.

You aren't going to break a Fortune 100 bank's retail app with a textbook SQLI. Those apps have been audited several times over. It would follow from your worldview that those apps simply don't get attacked. Of course they'll get attacked.

Also: padding oracles? HMAC timing attacks? Not rocket surgery.

I think we're talking about two different things here. You seem to be talking about attacks against the application itself like SQLI, etc. But I'm talking about attacks on the much larger numbers of users of the system.

Pick the random Fortune 100 bank app and wouldn't it be more fruitful to attack the pc's of the clients rather than the server? You've got probably millions of users of the application, most of which are barely secure in the first place. As you said, the web server side is going to be the toughest link in the chain. Not impervious, but certainly difficult. Seems much more likely the hacker/cracker will target the users. In such an attack, the crypto is not the thing attacked.

Both attacks happen routinely. A serverside crypto flaw that lets users impersonate other users is not just something fun to talk about; that's an emergency patch for most sensitive apps.

Yep, so apply the patch. Now what do you do about your millions of insecure clients running unpatched, out-dated OS/browsers? How do you solve that problem? Security folks don't want to talk about that because it's hard. The client-side is a much larger number of opportunities and much weaker link in the chain. Yes, you need to deal with both, but it's hard to find discussion on the latter, and a lot on the former.

Yes, the sun is still spinning on its axis, slowly burning its way through our atmosphere and hastening the inevitable demise of our species, whether or not you patch the ASP.NET CBC padding oracle. But for today, can we just focus on the padding oracle?

Reply on news.ycombinator.com