[Dataloss] Fringe: e-banking not yet secure
jericho at attrition.org
Fri Jul 25 02:26:18 UTC 2008
ISN posted the article as well, cross-posting my reply.
: Security flaws plague majority of e-banking sites
: Over 75% of banking Web sites contain fundamental design flaws that
: could put customers at risk from cyber thieves, according to a study (of
: 214 bank web sites)conducted by researchers at the University of
Unfortunately, all I can find are articles mentioning the study. It still
isn't available on Atul Prakash's home page . Since all we have to go
on right now are sound bytes and brief summaries, it is very easy to tear
large holes in the results. I encourage Prakash and his team to make the
original research more readily available.
: The flaws are not bugs that can be easily fixed with a patch, but are
: systemic, stemming from the flow and layout of the sites.
The flaws are often very easy to fix, and do not require much
work from the bank.
: 47% placed secure login boxes on insecure pages.
While a bad practice, this doesn't translate to "attackers can get access
to customer information" necessarily. "He says this allows hackers to
re-route data entered in the boxes or create a spoof page to harvest
information." First, to re-route data entered in the boxes relies on
something more than a mixed HTTP/S page. Exploiting cross-frame scripting
in some browsers would be a good idea, but that can be blocked regardless
of the page being served over SSL. Second, bad guys can spoof pages
regardless of the presence of SSL, yet Prakash suggests otherwise.
"Prakash says in a wireless situation, it's possible to conduct this
man-in-the-middle attack without changing the bank URL for the user, so
even a vigilant customer could fall victim."
Certainly a risk, but the amount of customers accessing their bank over
unsecured wireless are probably very minimal and changes the requirements
of exploitation considerably.
: 55% put contact information and security advice on insecure pages.
Again, having a static /contact.html on the legitimate domain, not served
over SSL is not a vulnerability, and does not lead to customers being at
risk from "hackers getting access to customer information". The summary
and introduction to the article is poorly worded and misleading.
: Some banks use social security numbers or e-mail addresses as user IDs.
This is definitely a bad practice and commonly seen, but this is half of
the information needed to authenticate. Brute forcing a list of login IDs
is time consuming, brute forcing valid passwords for them on top of that
is very time consuming. There are certainly controls that can be put in
place to make harvesting attacks more costly, regardless of the login name
: 28% don't state a policy on passwords, or allow weak passwords.
Yes, they should state their policy, but how many of the 28% don't state
the policy yet enforce a relatively strong one? This number is a poor
I have a hard time believing that Prakash and his team got permission to
test 214 bank web sites. If they did, it was still done without
authentication based on the results in the article. The few results they
do have are not near the risk implied by the summary wording or have
caveats on exploitation. None of them are real eye-openers as each one
would likely result in the compromise of a handful of accounts. While
certainly bad, that is insignificant compared to an SQL injection or
privilege escalation attack that allowed cross-user information disclosure
All said and done, this research is quite limp so far.
More information about the Dataloss